 |
|
| If you can't view the Datasheet, Please click here to try to view without PDF Reader . |
|
|
|
| If you can't view the Datasheet, Please click here to try to view without PDF Reader . |
|
|
| Datasheet File OCR Text: |
| ATECC608A prelim i nary datasheet ?2017 microchip technology page 1 1111- cryptoauth - ATECC608A - datasheet_08/06/2017 microchip confidential for release only under non_disclosure agreement microchip cryptoauthentication device features ? cryptographic co - processor with secure hardware - based key storage ? protected storage for up to 16 keys , certificates or data ? hardware support for asymmetric sign, verify, key agreement ? ecdsa: fips186 - 3 e lliptic curve digital signature ? ecdh: fips sp800 - 56 a elliptic curve diffie - hellman ? nist standard p256 elliptic curve support ? hardware support for symmetric algorithms ? sha - 256 & hmac hash including off - chip context save/restore ? aes- 128: encrypt/decrypt, galois field multiply for gcm ? networking key management support ? turnkey prf/hmac calculation for tls 1.2 & 1.3 ? ephemeral key generation and key agreement in sram ? small message encryption wit h keys entirely protected ? secure boot support ? full ecdsa code signature validation, optional stored digest/signature ? optional communication key disablement prior to secure boot ? encryption/authentication for messages to prevent on - board attacks ? internal high - quality fips 800 - 90 a/b/c random number generator (rng) ? two high - endurance monotonic counters ? guaranteed unique 72 - bit serial number ? two interface options available ? high - speed single pin inter face with one gpio pin ? 1mhz standard i 2 c interface ? 1.8v to 5.5v io levels, 2.0v to 5.5v supply v oltage ? <150na sleep current ? 8 - pad udfn , 8 - lead soic, and 3 - lead contact packages applications ? iot network endpoint key management & exchange ? encryption for small messages and pii data ? secure boot and protected download ? ecosystem control, anti - cloning
ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 2 ? 2017 microchip technology pin configuration and pinouts table 1. pin configuration pin function nc no connect gnd ground sda serial data scl serial clock input v cc power supply figure 1. pinouts ATECC608A - preliminary ?2017 microchip technology page 3 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 table of contents 1 introduction ................................................................ ................................................. 6 1.1 applications ........................................................................................................................................... 6 1.2 device features .................................................................................................................................... 6 1.3 cryptographic operation ....................................................................................................................... 7 2 eeprom memory ................................................................ ........................................ 8 2.1 eeprom data zone ............................................................................................................................. 8 2.1.1 certificate storage .................................................................................................................... 9 2.2 eeprom configuration zone ............................................................................................................. 10 2.2.2 serial number (bytes 0 - 2 and 8-12) ....................................................................................... 12 2.2.3 revision number (bytes 4 -7) ................................................................................................. 12 2.2.1 i2c address (byte 16) ............................................................................................................ 12 2.2.2 gpio control (byte 16) .......................................................................................................... 13 2.2.3 counter match key (byte 18) ................................................................................................. 13 2.2.4 use lock (byte 68) ................................................................................................................. 14 2.2.5 volatile key usage permission (byte 69) ............................................................................... 14 2.2.6 secure boot configuration (bytes 70 -71) ............................................................................... 1 5 2.2.7 special kdf initialization vector function (bytes 72 - 74) ....................................................... 15 2.2.8 io protection (chipoptions : bytes 90 - 91) ............................................................................. 16 2.2.9 x.509 certificate validation format (bytes 92 - 95) ................................................................ 16 2.2.10 slotconfig (bytes 20 to 51) ..................................................................................................... 17 2.2.11 keyconfig (bytes 96 thru 127) ............................................................................................... 20 2.3 eeprom one time programmable (otp) zone ................................................................................ 23 2.4 eeprom locking ............................................................................................................................... 23 2.4.1 conf iguration zone locking .................................................................................................... 24 2.4.2 data and otp zone locking .................................................................................................. 24 2.4.3 individual slot locking ............................................................................................................ 24 3 static ram (sram) memory ................................................................ ..................... 26 3.1 tempkey ............................................................................................................................................. 26 3.2 message digest buffer ........................................................................................................................ 27 3.3 alternate key buffer ............................................................................................................................ 27 3.4 sha context buffer ............................................................................................................................. 27 3.5 persistent latch .................................................................................................................................. 27 4 security information ................................ ................................ .................................. 29 4.1 cryptographic standards ..................................................................................................................... 29 4.1.1 sha -256 ................................................................................................................................. 29 4.1.2 hmac/sha -256 ..................................................................................................................... 29 4.1.3 tls v1.2 pseudo random function (prf) ............................................................................ 29 4.1.4 hmac - based extract -and- expand kdf (hkdf) .................................................................... 29 4.1.5 elliptic curve digital signature algorithm (ecdsa) ............................................................... 29 4.1.6 elliptic curve diffie - hellman (ecdh) ..................................................................................... 30 4.1.7 advanced encryption standard (aes) ................................................................................... 30 4.2 secure boot ........................................................................................................................................ 30 4.2.1 secure boot speed optimization ............................................................................................. 30 4.2.2 secure boot wire protection .................................................................................................... 31 4.3 public key update ............................................................................................................................... 31 ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 4 ? 2017 microchip technology 4.4 key uses and restrictions .................................................................................................................. 32 4.4.1 diversified keys ...................................................................................................................... 32 4.4.2 rolled keys ............................................................................................................................ 32 4.4.3 created ecc keys ................................................................................................................. 33 4.4.4 created secret keys .............................................................................................................. 33 4.4.5 high endurance monotonic counters ..................................................................................... 33 4.4.6 passwo rd checking ................................................................................................................ 33 4.4.7 transport keys ....................................................................................................................... 34 4.4.8 authorized keys ..................................................................................................................... 35 4.5 security features ................................................................................................................................ 35 4.5.1 physical security .................................................................................................................... 35 4.5.2 random number generator (rng) ........................................................................................ 35 5 general i/o information ................................................................ ............................. 37 5.1 byte and bit ordering .......................................................................................................................... 37 5.1.1 ecc key formatting .............................................................................................................. 37 6 single - wire interface ................................................................ ................................. 38 6.1 i/o tokens ........................................................................................................................................... 38 6.2 i/o flags .............................................................................................................................................. 39 6.3 synchronization ................................................................................................................................... 40 6.3.1 i/o timeout ............................................................................................................................. 40 6.3.2 synchronization procedures ................................................................................................... 40 7 i 2 c interface ................................ ................................ ................................................ 41 7.1 i/o conditions ..................................................................................................................................... 41 7.1.1 devi ce is asleep ..................................................................................................................... 41 7.1.2 device is awake ..................................................................................................................... 41 7.2 i 2 c transmission to ATECC608A ........................................................................................................ 43 7.2.1 word address values ............................................................................................................. 44 7.2.2 command completion polling ................................................................................................ 44 7.3 sleep sequence .................................................................................................................................. 44 7.4 idle sequence ..................................................................................................................................... 44 7.5 i 2 c transmission from the ATECC608A ............................................................................................. 45 7.6 address counter ................................................................................................................................. 45 7.7 smbus timeout ................................................................................................................................... 46 7.8 i 2 c synchronization ............................................................................................................................. 46 8 general purpose i/o pin ................................ ................................ ............................ 48 9 electrical characteristics ................................................................ .......................... 49 9.1 absolute maximum ratings* ............................................................................................................... 49 9.2 reliability ............................................................................................................................................. 49 9.3 ac parameters: all i/o interfaces ....................................................................................................... 50 9.3.1 ac parameters: single - wire interface ................................................................................... 51 9.3.2 ac parameters: i 2 c interface ................................................................................................. 52 9.4 dc parameters: all i/o interfaces ....................................................................................................... 53 9.4.1 v ih and v il specifications ....................................................................................................... 54 10 general command information ................................................................ ................ 56 10.1 i/o groups ........................................................................................................................................... 56 10.2 command packets .............................................................................................................................. 56 ATECC608A - preliminary ?2017 microchip technology page 5 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 10.3 status/error codes .............................................................................................................................. 57 10.4 command summary and execution times ......................................................................................... 58 10.4.1 command summary .............................................................................................................. 58 10.4.2 command execution times ..................................................................................................... 59 10.5 address encoding ............................................................................................................................... 61 10.5.1 zone encoding ....................................................................................................................... 61 10.6 watchdog failsafe ............................................................................................................................... 64 11 detailed command descriptions 11.1 aes command .................................................................................................................................... 65 11.2 checkmac command ......................................................................................................................... 66 11.3 counter command ........................................................................................................................... 68 11.4 derivekey command ....................................................................................................................... 69 11.5 ecdh command .................................................................................................................................. 71 11.6 gendi g command .............................................................................................................................. 73 11.7 genkey command .............................................................................................................................. 77 11.8 info command .................................................................................................................................. 79 11.9 kdf command .................................................................................................................................... 81 11.10 lock command ..................................................................................................................... 85 11.11 mac command ....................................................................................................................... 86 11.12 nonce command ................................................................................................................... 88 11.13 privwrite command .......................................................................................................... 90 11.14 random command ................................................................................................................. 91 11.15 read command ..................................................................................................................... 92 11.16 secureboot command ........................................................................................................ 94 11.17 selftest command ............................................................................................................ 97 11.19 sha command ....................................................................................................................... 98 11.20 sign command ................................................................................................................... 101 11.21 up dateextra command .................................................................................................... 103 11.22 verify command ............................................................................................................... 104 11.23 write command ................................................................................................................. 107 11.23.1 input data encryption ........................................................................................................... 108 12 compatibility ................................................................ ............................................ 109 12.1 microchip atecc508a ..................................................................................................................... 109 12.2 microchip atsha204a, atecc108a ............................................................................................... 109 13 mechanical ................................................................ ............................................... 110 13.1 pinouts 110 13.2 wiring configuration for single - wire interface .................................................................................. 110 14 ordering information ................................................................ ............................... 111 14.1 part marking ...................................................................................................................................... 111 15 errata ................................ ................................ ........................................................ 112 16 package drawings ................................................................ ................................... 113 16.1 8 - lead soic ...................................................................................................................................... 113 16.2 8 - pad udfn ...................................................................................................................................... 114 16.3 3 - lead contact .............................................................................................................................. 115 17 revision history ................................................................ ...................................... 116 ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 6 ? 2017 microchip technology 1 introduction 1.1 applications the microchip ? ATECC608A is a member of the microchip cryptoauthentication ? family of high - security cryptographic devices which combine world - class hardware - based key storage with hardware cryptographic accelerators to implement various authentication and encryption protocols. the ATECC608A has a flexible command set that allows use in many applications, including the following: ? network/iot node endpoint security manage node identity authentication and session key creation & management. supports the entire ephemeral session key generation flow for multiple protocols including tls 1.2 (and earlier) and tls 1.3 ? secure boot support the mcu host by validating code digests and optionally enabling communication keys on success. various configurations to offer enhanced performance are available. ? small message encryption hardware aes engin e to encrypt and/or decrypt small messages or data such as pii information. supports all aes modes. additional gfm calculation function to support aes - gcm. ? key generation for software download supports local protected key generation for downloaded images. both broadcast of one image to many systems, each with the same decryption key, or point - to - point download of unique images per system is supported. ? ecosystem control and anti - counterfeiting validates that a system or component is authentic and came from the oem shown on the nameplate. the ATECC608A is generally compatible with the atecc508a when properly configured. see section 12.1 for more details. 1.2 device featur es the ATECC608A includes an eeprom array which can be used for storage of up to 16 keys, certificates, miscellaneous read/write, read - only or secret data, consumption logging, and security configurations. access to the various sections of memory can be re stricted in a variety of ways and then the configuration can be locked to prevent changes. access to the device is made through a standard i 2 c interface at speeds of up to 1mb/s (see section 7 , i2c interface ). the interface is compatible with standard serial eeprom i 2 c interface specifications. the device also supports a single - wire interface (swi), which can reduce the number of gpios required on the system processor, and/or re duce the number of pins on connectors (see section 6 , single - wire interface ). if the single - wire interface is enabled, the remaining pin is available for use as a gpio, an authenticated output or tamper input. each ATECC608A ships with a guaranteed uni que 72- bit serial number. using the cryptographic protocols supported by the device, a host system or remote server can verify a signature of the serial number to prove that the serial number is authentic and not a copy. serial numbers are often stored in a standard serial eeprom; however, these can be easily copied with no way for the host to know if the serial number is authentic or if it is a clone. the ATECC608A features a wide array of defense mechanisms specifically designed to prevent physical attack s on the device itself, or logical attacks on the data transmitted between the device and the system (see section 4.5 , ATECC608A - preliminary ?2017 microchip technology page 7 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 security features ). hardware restrictions on the ways in which keys are used or generated provide further defense against certain styles of attack. 1.3 cryptographic operation the ATECC608A implements a compl ete asymmetric (public/private) key cryptographic signature solution based upon elliptic curve cryptography and the ecdsa signature protocol. the device features hardware acceleration for the nist standard p256 prime curve and supports the complete key lif e cycle from high quality private key generation, to ecdsa signature generation, ecdh key agreement, and ecdsa public key signature verification. the hardware accelerator can implement such asymmetric cryptographic operations from ten to one - thousand times faster than software running on standard microprocessors, without the usual high risk of key exposure that is endemic to standard microprocessors. the ATECC608A also implements aes - 128, sha256 and multiple sha derivatives such as hmsc(sha), prf (the key d erivation function in tls) and hkdf in hardware. support is included for the galois field multiply (aka ghash) to facilitate gcm encryption/decryption/authentication. the device is designed to securely store multiple private keys along with their associat ed public keys and certificates. the signature verification command can use any stored or an external ecc public key. public keys stored within the device can be configured to require validation via a certificate chain to speed - up subsequent device authent ications. random private key generation is supported internally within the device to ensure that the private key can never be known outside of the device. the public key corresponding to a stored private key is always returned when the key is generated and it may optionally be computed at a later time. the ATECC608A can generate high - quality random numbers using its internal random number generator. this sophisticated function includes runtime health testing designed to ensure that the values generated from the internal noise source contain sufficient entropy at the current time, with the current device and under the current voltage and temperature conditions. the random number generator is designed to meet the requirements documented in the nist 800 - 90a, 80 0 - 90b and 800 - 90c documents. these random numbers can be employed for any purpose, including usage as part of the device?s crypto protocols. because each random number is guaranteed to be essentially unique from all numbers ever generated on this or any ot her device, their inclusion in the protocol calculation ensures that replay attacks (i.e. re - transmitting a previously successful transaction) will always fail. the ATECC608A also supports a standard hash - based challenge - response protocol in order to allow its use across a wide variety of additional applications. in its most basic instantiation, the system sends a challenge to the device, which combines that chall enge with a secret key via the mac command and then sends the response back to the system. the device uses a sha - 256 cryptographic hash algorithm to make that combination so that an observer on the bus cannot derive the value of the secret key, but preserv ing that ability of a recipient to verify that the response is correct by performing the same calculation with a stored copy of the secret on the recipient?s system. there are a wide variety of variations possible on this symmetric challenge/response theme . ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 8 ? 2017 microchip technology 2 eeprom memory the eeprom memory contains a total of 11,200 bits and is divided into the following zones: table 2 -1. ATECC608A zones zone description nomenclature data zone of 1,208 bytes (9.7kb) split into 16 general purpose read - only or read/write memory slots of 36 bytes (288 bits), 72 bytes (576 bits), or 416 bytes (3,328 bits) each that can be used to store keys (public or private), signatures, certificates, calibration, model number, or other information, typically that relate to the item to which the atecc 608a device is attached. slot[yy] = the entire contents stored in slot yy of the data zone. configuration zone of 128 bytes (1,024 - bit) eeprom that contains the serial number and other id information, as well as, access the permission information for each slot of the data memory. sn[a:b] = arrange of bytes within a field of the configuration zone. one time p rogrammable (otp) zone of 64 bytes (512 bits) of otp bits. prior to locking the otp zone, the bits may be freely written using the standard write command. the otp zone can be used to store read - only data. otp[bb] = a byte within the otp zone, while otp[aa:bb] indicates a range of bytes. terms discussed within this document will have the following meanings: table 2 -2. document terms term meaning block a single 256 - bit (32 - byte) area of a particular memory zone. the industry sha - 256 documentation also uses the term block to indicate a 512 - bit section of the message input. within this document, this convention is used only when describing hash input messages. keyid keyid is equivalent to the slot number for those slots designated to hold key values. key 1 (sometimes referred to as key[1]) is stored in slot[1] and so on. while all 16 slots can potentially hold keys, those slots which are configured to permit clear - text reads would not normally be used as private or secret keys by the crypto commands. mode:b indicates bit b of the parameter mode. sram contains input and output buffers, as well as, state storage locations. see section 3 2.1 eeprom data z one the data zone is broken into 16 slots, for which access restrictions are individually programmable. while all slots can be used for private or secret keys or user data, only slots 8 thru 15 are large enough to store an ecc public key or ecdsa certifica te/signature. when a slot is used for a private or secret key, the excess memory not required by the particular algorithm is in general unusable. the following table lists the typical uses for each group of slots, along with any special characteristics of slots within that group. ATECC608A - preliminary ?2017 microchip technology page 9 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 table 2 -3. data zone slot blocks (1) bytes bits typical use notes 0 C 7 2 36 288 private or secret key can also be used for data. 8 13 416 3328 data reads and writes can be configured to be restricted in the same manner as all other slots. if this slot is used as a key, then the remaining bytes not required for the secret or private key storage will be ignored. 9 C 15 3 72 576 public key, signature or certificate for the curve supported by this device, these slots are large enough to contain both the x and y components of an ecdsa public key or the r and s components of an ecdsa signature. note 1. the last block in some data slots contains fewer than 32 bytes. data slots which contain ecc public or private keys should be formatted according to section 5.1.1 , ecc key formatting . the device uses the keytype and pubinfo fields of keyconfig to determine what is stored in a slot. private keys can never be read from the device under any circumstances. ecc key slot contents may not be usable by the ecc commands unless they are validated as follows: ? ecc private keys prior to the first privwrite or genkey(create) command execution on a slot, priv ate keys are invalid. the key may also be invalid if the privwrite command is started, but power is interrupted prior to its completion. ? ecc public keys the key must be validated using an input signature and the ecc verify command if the pubinfo bit of k eyconfig is one. if that bit is zero, then ecc usage does not depend on the key verify operation. these keys may be stored in slots 8 thru 15 only . this feature is optional. data slots may also contain aes keys. if they are to be used by the aes encrypt/decrypt command, they must be tagged with the aes data type. either two or four keys may be stored within a slot, depending on the size of the slot. 2.1.1 certificate storage certificates of private keys stored with the ATECC608A generally take more stor age than the 72 bytes (576 bits) which are available in slots 9 thru 15. assuming that the certificate authority signing key is a 256 bit ecc key, then these certificates can be efficiently stored within a single slot in the following manner: 1. the first 8 b ytes of the key slot can be used to identify a template from a table stored in the host memory. this table can include static data such as the algorithm, issuer?s name, use restrictions, etc. these bytes can also provide compressed versions of variable inf ormation such as generation and expiry dates, etc. 2. the public key component of the initial section of the certificate can be computed based on the private key stored within the ATECC608A. 3. the last 64 bytes can be used to store the authority?s ecdsa signatu re of the tbs section. slot 8 may contain sufficient space to store a single ecc certificate in uncompressed format. also, uncompressed certificates can be split in pieces and stored in multiple slots. ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 10 ? 2017 microchip technology 2.2 eeprom configuration zone the 128 bytes in the configu ration zone contains the manufacturing identification data, general device and system configuration information and access restriction control values for the slots within the data zone. it is organized as four blocks of 32 bytes each. the values of these b ytes can always be obtained using the read command. system designers should take great care to ensure that the access restrictions are appropriate for the information that is stored within the slot. particular notice should be taken for those slots that are indirectly referenced ? as a read/write/authorization parent, as the target of a copy function (typically calculated as keyid | 1) or the keys used for io protection, gpio, countermatch or secure boot. the bytes of this zone are arranged as shown the t able below: table 2 -4. configuration zone byte name description write read 0 ? 3 sn[0:3] part of the serial number value. see section 2.2.2 never always 4 ? 7 revnum device revision number. see section 2.2.3 never always 8 ? 12 sn[4:8] part of the serial number value. see section 2.2.2 never always 13 aes_enable bit 0: 0 = the aes command and aes mode of the kdf command are disabled. 1 = the aes operations are enabled. bits 1 - 7: set by microchip and cannot be changed. the value in these bits will vary and software should not depend on any particular state. never always 14 i2c_enable bit 0: 0 = the device operates in single - wire interface mode. 1 = the device operates in i2c interface mode. bits 1- 7: set by microchip and cannot be changed. the value in these bits will vary and software should not depend on any particular state. never always 15 reserved set by microchip . never always 16 i2c_address when i2c_enable:0 is one, this field is the i2c_address with a default value of 0xc0 . see section 2.2.1 . when i2c_enable:0 is zero the chip operate s in single wire mode and this this field controls the gpio function. see section 2.2.3 . if config unlocked always 17 reserved reserved. must be zero. 18 countmatch counter match function control byte, see section 2.2.1 bit 0: counter match enable. if 0, counter match function is disabled. bit 1 - 3: must be zero. bits 4 - 7: countmatchkey, slot to be used for counter match. if config unlocked always ATECC608A - preliminary ?2017 microchip technology page 11 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 byte name description write read 19 chipmode bit 0: i2c address userextraadd mode. see section 2.2.1 . 0 = i2c address is stored in byte 16 1 = i2c address is in byte 85 if that is not zero bit 1: ttlenable. see figure 9 - 5 and figure 9 - 6 0 = input levels use a fixed reference. 1 = input levels are v cc referenced. bit 2: watchdog duration. microchip recommends this be set to zero for the best security 0 = t watchdog is 1.3s, nominal. 1 = t watchdog is 10.0s, nominal. bits 3 - 7: clock divider . only 00000, 01101 (0x0d) and 00101 (0x05) are legal. see sections 0 and section table 9 - 4 if config unlocked always 20 ? 51 slotconfig two bytes of access and usage permissions and controls for each slot of the data zone. see section 2.2.10 , slotconfig (bytes 20 to 51) . if config unlocked always 52 ? 59 counter[0] monotonic counter that can optionally be connected to keys via the slotconfig.limiteduse bit. can count to a value of 2,097,151 and can never be decremented. if config unlocked always 60 ? 67 counter[1] second monotonic counter, not connected to any keys. if config unlocked always 68 uselock configuration for transport locking. see section 2.2.4 bits 0 - 3: uselockenable. bits 4 - 7: uselockkey if config unlocked always 69 volatilekey permission volatile key permission configuration. see section 2.2.5 . bits 0 - 3: volatilekeypermitslot bits 4 - 6: must be zero bit 7: volatilekeypermitenable. if config unlocked always 70 ? 71 secureboot this byte controls the special secure boot functionality of the device. see sections 2.2.6 and 4.2 . if config unlocked always 72 kdfivloc index within the kdf(hkdf) input string where the two bytes stored below (kdfivstr) should be found. see section 2.2.7 if config unlocked always 73 ? 74 kdfivstr two byte kdf iv string that must be found in the kdf message for the kdf(hkdf) special iv mode. see section 2.2.7 if config unlocked always 75 ? 83 reserved must be zero if config unlocked always 84 userextra one byte value that can be modified via the updateextra command after the data zone has been locked. can be written via updateextra only if it has a value of zero. via update extra cmd only always 85 userextraadd if non - zero, the i2c address to which this device will respond on the bus. can be written via updateextra only if it has a value of zero. via update extra cmd only always 86 lockvalue controls the ability to write the otp and data zones. 0x55 = unlocked; 0x00 = locked. see section 2.4 , eeprom locking . via lock command only always ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 12 ? 2017 microchip technology byte name description write read 87 lockconfig controls the ability to modify the configuration zone. 0x55 = unlocked; 0x00 = locked. see section 2.4 , eeprom locking . via lock command only always 88 C 89 slotlocked a single bit for each slot. if the bit corresponding to a particular slot is zero, the contents of the slot cannot be modified under any circumstances. see section 2.4.3 if config unlocked, via lock command always 90 C 91 chipoptions bit 0: power on self test. if 1, the sha, aes and rng self tests will be automatically executed on wake or power - on. bit 1: io protection key enable. see section 2.2.8 bit 2: kdf aes enable. if 1, the aes mode of kdf is e nabled. if 0, the kdf command can only be run with the prf and hkdf algorithms. bits 3 - 7: must be zero bits 8 - 9: ecdh protection bits. see section 2.2.8 bits 10 - 11: kdf protection bits. see sections 2.2.7 and 2.2.8 bits 12 - 15: io protection key. see section 2.2.8 if config unlocked always 92 C 95 x509format x.509 certificate validation formatting. see section 2.2.9 if config unlocked always 96 C 127 keyconfig two bytes of additional access and usage permissions and controls for each slot of the data zone. see section 2.2.11 , keyconfig. if config unlocked always 2.2.2 serial number (bytes 0 - 2 and 8 - 12) nine bytes (sn[0:8]) that together form a unique 72 bit value that is never repeated for any device in the cryptoauthentication family. it can be used for any purpose by external firmware and can be the basis of a diversified key calculation. the serial n umber can never be written under any circumstances and can always be read, regardless of the state of the lock bits. the serial number is divided into two groups: sn[0:1] and sn[8] the values of these bits are fixed at manufacturing time in most versions of the ATECC608A. their default value is 0x01 23 ee . these 24 bits are usually included in the hash computations that the ATECC608A makes. sn[2:3] and sn[4:7] the values of these bits are programmed by microchip during the manufacturing process and are different for every die. these 48 bits are optionally included in some cryptographic computations that are made by the ATECC608A. 2.2.3 revision number (bytes 4 - 7) four bytes of information that are used by microchip to provide manufacturing revision information . these bytes can be freely read but they should never be used by system software because they may be revised by microchip from time to time. 2.2.1 i2c address (byte 16) when the device is configured to use the i 2 c interface then either byte 16 or 85 contains th e device address to which this ATECC608A will respond. the selection of which byte to use is contained in the first bit of chip mode (byte 19). ATECC608A - preliminary ?2017 microchip technology page 13 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 in those situations in which the configuration zone is locked prior to insertion in the end system and there are multiple ATECC608A devices in the system, it may be necessary to be able to select among a set of ATECC608A devices. this can be accomplished by using the updateextra command to write a non - zero value to location 85. once written to 85, the ATECC608A shou ld be powered off or put to sleep. on wake or power - on, it will then respond to the address programmed in byte 85. regardless of the value of chipmode:bit 0, the ATECC608A will use the i2c address in byte 18 as long as byte 85 contains a value of zero. onc e byte 85 has been written to a value other than 0, it can no longer be written. there is no method to program the ATECC608A to respond to a device address of 0. regardless of the source of the address, the lsb of the address byte is always ignored by the ATECC608A. 2.2.2 gpio control (byte 16) when the device is configured to operate in single wire interface mode, these bits are used to control the gpio pin. (see section 8 ). bits 0 - 1: gpio mode 00 = disabled. scl pin is unused should be tied low on the board. 01 = authorization modes, bit 3 determines device operation. 10 = input. current value on the scl pin returned by info command. 11 = output. scl may be driven high or low by info command. bit 2: gpio default . default state of scl pin on power - up when configured as an output. bit 3: gpio auth mode . selects between the authorization modes. must be zero if io_mode is not 01. 0 = aut horization output mode. when an authorization is successfully performed on the slot in signalkey, the scl pin is asserted. 1 = intrusion detection mode. persistent latch is set via authorization and cleared if scl falls. bits 4 - 7: signalkey . if io_mode is 01 , the slot number for the gpio authorizing key. for all other modes, must be 0000 . 2.2.3 counter match key (byte 18) the counter match function in the ATECC608A provides a mechanism of altering the limit to which the first monotonic counter (counter 0) can be incremented. key usage can be connected to counter 0 (see section 4.4.5 ) to prevent their use when the counter is at its limit. if the counter matc h enable bit in this byte is zero, then the counter match function is disabled and the counter has to reach its natural limit before the keys are disabled. the countermatchkey field in this byte defines the key slot which contains the value to compare with the current counter value. there are a few details to be followed when writing a limit value to this slot: ? the least significant 5 bits of the value in the key slot is ignore d. this means that the granularity of a change in the limit is 32 iterations. the limit value should be written as a 32 bit number with the least significant 5 bits as 0 and a net value no greater than the maximum count as defined below in section 4.4.5 . ? to provide reliable operation, this 4 byte (32 bit) value should be repeated in the second 4 bytes of the key slot. ? the countermatchkey slot must not have the issecret bit set. it is still fine to require both encryption and macs on the write command for this slot. ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 14 ? 2017 microchip technology 2.2.4 use lock (byte 68) this byte controls the transport locking function of the ATECC608A. when this function is enabled, general purpose use of the device is prohibited until the device is cryptographically enabled. when locked, only the read, nonce and checkmac commands are permitted. to enable the device, the host system should use the nonce command to generate a nonce value. tha t nonce should then be combined using sha following the sequence described in the checkmac command below. the resulting digest should be sent to the checkmac command with the source key pointing to uselockkey. if the ATECC608A can validate the digest, then it will automatically clear uselockenable and allow normal use. the bits in this byte are encoded as follows: bits 0 - 3: uselockenable . if 0x0a, then only read, nonce and checkmac commands are permitted. if any other value, then this function is not enable d, the uselockkey field is ignored and all commands complete normally. bits 4 - 7: uselockke y. the slot id of the key that can be used with checkmac to enable full use of the chip the following two best practices should be observed in order to obtain the appropriate security: ? set the reqrandom bit in keyconfig for uselockkey. this will require that each device be enabled via a separate transaction with the host system using a random number generated within the ATECC608A chip. if this bit is not set, then t he identical sequence can be sent to every device to enable it, leaving open the possibility of an attack on the host enablement system and the loss of that sequence. ? configure the uselockkey slot to allow derivekey(roll) without authorization ? writeconfi g = 0010. after the device has been unlocked, then the authorizing key can be destroyed via combination with a random number (generated in any manner the host may desire) on the input, preventing any possibility of future use. 2.2.5 volatile key usage permission (byte 69) this byte controls the volatile permission function of the ATECC608A. when this function is enabled for a particular key slot, general purpose use of that slot will be prohibited until cryptographically enabled. the permission status is stored i n the persistent latch and is retained during sleep, idle and active modes. see section 3.5 for more information on the persistent latch. one use o f this function is to connect a particular ATECC608A to a particular host mcu on a board. on power - up, the host would enable normal key usage during boot and continue operation as before. if the ATECC608A is removed from the board, then without knowledge o f the shared key, the remaining keys on the ATECC608A would be unusable. the secret used to facilitate the volatile key permission should be a unique value that is stored in both the mcu and the ATECC608A at board manufacturing. one fine option is to share this key with the key used for io protection. this key can be generated via the ATECC608A random number generator and stored within a key slot and then slot locked. the same value should be stored in a safe place within the mcu. this function may also all ow factory enablement of keys within systems that contain a battery. if the device is removed from the system, use of the keys will not be permitted. to enable the keys, the host system should use the nonce command to generate a nonce value. that nonce sho uld then be combined using sha following the sequence described in the checkmac command below. the resulting digest should be sent to the checkmac command with the source key pointing to volkeypermitslot. then the info(mode=4) command can be run to write t he persistent latch to a value of 1. the bits in this byte are encoded as follows: bits 0 - 3: volkeypermitslot . the slot containing the key which is used to set or clear the persistent latch via the info command. ATECC608A - preliminary ?2017 microchip technology page 15 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 bits 4 - 7: must be zero. bit 7: volkeypermitenable . if 0, then this function is disabled and control of the persistent latch may occur via other means. if 0, volkeypermitslot is ignored. best practice is to set the reqrandom bit in keyconfig for volkeypermitslot. this will require that the keys be enabled via a separate transaction with the host system using a random number generated within the ATECC608A chip. if this bit is not set, then the enable sequence can be stored by an attacker and replayed in a different environment. 2.2.6 secure boo t configuration (bytes 70 - 71) these two bytes control the operation of the secure boot functionality of the device. in general, the secureboot command makes use of these configuration bits to ensure that the proper sequences are executed. see section 4.2 for a complete description of the secure boot capability supported by the device. bits 0 - 1: securebootmode 00: secure boot functionality disabled. 01 : full secure boot (fullboth). both digest and signature must be passed to the chip on boot. 10: stored secure b oot (fullsig). after first successful secure boot, signature is stored and subsequent boots do not require signature to transmitted 11: stored s ecure boot (fulldig). after first successful secure boot, digest is stored and on subsequent boots the digest is compared without ecc verify bits 2: must be zero. bit 3: securebootpersistentenable . if 1, then on successful execution of the secureboot comma nd, the persistent latch will be set. if key usage is tied to the persistent latch via the persistentdisable bit in keyconfig, then those keys will not be usable until secure boot has successfully completed. bit 4: securebootrandnonce . if 1, then the input code digest for the secureboot command must be encrypted and the nonce used for the digest encryption must use the ATECC608A random number generator . when the input is encrypted, the output always includes a mac. if 0, input encryption is optional and is controlled solely via the mode bit of the secureboot command. if 0, use of the ATECC608A random number generator is not required. bits 5 - 7: must be zero. bits 8 - 11: securebootsigdig . slot number containing the stored digest or signature to be used during secure boot if a previous secure boot has validated the digest or signature. bits 12 - 15: securebootpubkey . slot number cont aining the public key used for validation of the code signature. 2.2.7 special kdf initialization vector function (bytes 72 - 74) the result of the kdf command computation can be prevented from being sent to the host mcu in the clear via the io protection field (below) if so configured. while this is a secure method for use it is not optimal for the hkdf initialization vector values. this is im portant when using the on - chip aes engine because that command requires that the mode handling for any mode other than ecb be performed externally in the host mcu. this special function allows the kdf command to bypass that the io protection field and allo w the kdf result to be placed in the output buffer in the clear if all of the following conditions are met: 1. the kdf algorithm must be hkdf and the mode should specify that the output is in the clear 2. the length of the input string must be at least as long a s config.kdfivloc + 2 3. the two bytes starting at index config.kdfivloc must match the two bytes stored at config.kdfivstr ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 16 ? 2017 microchip technology this function can be disabled by setting the index value (config.kdfivloc) to 0xf0, which exceeds the size of the input buffer and will never result in a legal match. 2.2.8 io protection (chipoptions : bytes 90 - 91) the ATECC608A provides a method to protect the io transmissions between it and the host mcu for the ecdh, kdf, verify and secureboot commands. other commands provide protection for t he result as described elsewhere. the remaining bits within the chip options word are used for other functions, this section includes only those bits which pertain to the io protection function. it is expected that a typical implementation would involve ge neration of a random number at the first power - up of the board containing the ATECC608A and the host. this shared secret would be written into both the io protection key slot and a relatively secure place within the host mcu. once written it would be slot locked on the ATECC608A to prevent any changes. in such an implementation, every board would have a different secret protecting the transmissions between the ATECC608A and host. due to this, any possible attack on one system could not be directly translate d to a second. for the ecdh and kdf commands, io protection involves encrypting the data transmitted from the ATECC608A to the host mcu. for the verify command, io protection involves returning a validation mac with the output to ensure that a man - in - the - m iddle has not modified the result from the chip. the secureboot operation involves both encryption and authentication. bit 1: io protection enable . if 1, then the protection functions are enabled via the secret key stored in the io protection key slot. if 0, this function is disabled and the three fields below are ignored by the chip. bits 8 - 9: ecdh prot . restrictions on the way the ecdh command result can be used: 00 = output in the clear is ok, though encryption can still be indicated in the mode paramet er 01 = output is ok, but the result must be encrypted. the state of the encryption bit in the mode parameter will be ignored by the ecdh command. 10 = result must be stored in tempkey or and eeprom key slot, output on the bus is forbidden. 11 = do not use . bits 10 - 11: kdf prot . restrictions on the way the kdf command result can be used, coded identically as for ecdh above. bits 12 - 15: io protection key . keyid to be used for io protection. slotconfig.nomac must be set to 0 for this key. 2.2.9 x.509 certificate validation format (bytes 92 - 95) most x.509 certificates are too large to store in the slots of the ATECC608A. the device does, however, provide a method to store the public keys contained within an x.509 certificate and to prevent their use until the cert ificate has been validated. this sequence is controlled via the sha(public) and verify(validateexternal) commands. the four individual bytes within this format section are associated with the x.509 certificate formatting appropriate for specific of public keys stored within the device. if the value of the byte associated with a particular public key is zero, then these formatting restrictions are ignored and that public key can be validated with verify(validate) . unused bytes within this array must be zero, otherwise, the formatting must be as follows: bits 0 C 3: publicposition. the sha block number in which the public key must be inserted in the sha sequence for the verify(validateexternal) command to properly validate a public key. bits 4 C 7: templatelength. the total number of blocks in the entire sha sequence which are required for the verify(validateexternal) command to properly validate a public key. ATECC608A - preliminary ?2017 microchip technology page 17 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 2.2.10 slotconfig (bytes 20 to 51) the 16 slotconfig elements are used to configure the access protections for each of the 16 slots within the ATECC608A device. each configuration element consists of 16 bits, which control the usage and access for that particular slot or key. the slotconfig field is interpreted according to the following table when the data zone is locked. when the data zone is unlocked, these restrictions generally do not apply , and those slots not configured to contain private keys may freely be written and none may be read. table 2 -5. slotconfig bits (per slot) bit name description 0 ? 3 readkey use this keyid to encrypt data being read from this slot using the read command. see more information in the description for bit 6 in table 2 - 6. 0 = then this slot can be the source for the checkmac copy operation. see section 4.4.6 , password checking . ? do not use zero as a default. do not set this field to zero unless the checkmac co py operation is explicitly desired, regardless of any other read/write restrictions. slots containing private keys can never be read and this field has a different meaning: bit 0: external signatures of arbitrary messages are enabled. bit 1: internal s ignatures of messages generated by gendig or genkey are enabled. bit 2: ecdh operation is permitted for this key. bit 3: if clear, then ecdh master secret will be output in the clear. if set, then master secret will be written into slot n|1. ignored if bit 2 is zero. for slots containing public keys that can be validated (pubinfo is one, see section 2.2.11 , keyconfig), this field stored the id of the key that should be used to perform the validation. 4 nomac 1 = the key stored in the slot is intended for verification usage and cannot be used by the mac command. when this key is used to generate or modify tempkey, then that value may not be used by the mac command. 0 = the key stored in the slot can be used by all commands. 5 limiteduse 1 = the key stored in the slot is limited use and its use is controlled by counter0. see section 4.4.5 , high endurance monotonic counters . 0 = there are no usage limitations. 6 encryptread 1 = reads from this slot will be encrypted using the procedure specified in the read command using readkey (bits 0 ? 3 in this table) to generate the encryption key. no input mac is required. if this bit is set, then issecret must also be set (in addition, see the following table 2 -6 ). 0 = clear text reads may be permitted. 7 issecret 1 = the contents of this slot are secret C clear text reads are prohibited and both 4 - byte reads and writes are prohibited. this bit must be set if encryptread is a one or if writeconfig has any value o ther than always to ensure proper operation of the device. 0 = the contents of this slot should contain neither confidential data nor keys. the genkey and sign commands will fail if issecret is set to zero for any ecc private key. see table 2 - 6 for additional information. 8 ? 11 writekey use this key to validate and encrypt data written to this slot 12 ? 15 writeconfig controls the ability to modify the data in this slot. see table 2 - 7 , table 2 - 8 , table 2 - 10 , and 11.23. ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 18 ? 2017 microchip technology 2.2.10.2 read permissions read operations for most data slots are controlled by the state of issecret and encryptread, according to the following table. ecc private keys can never be read under any circumstances. table 2 -6. read operation permission issecret encryptread description 0 0 clear text reads are always permitted from this slot. slots set to this state should never be used as key storage. either 4 or 32 bytes may be read at a time. 0 1 prohibited. no security is guaranteed for slots using this code. 1 0 reads are never permitted from this slot. slots set to this state can still be used for key storage. 1 1 reads from this slot are encrypted using the encryption algorithm documented in the read command section below. the encryption key is in the slot spe cified by readkey. 4 - byte reads and writes are prohibited. 2.2.10.3 write permissions the 4 - bit writeconfig field is interpreted by the write, derivekey , and genkey commands as shown in table 2 - 7 , table 2 - 8 , and table 2 - 10 where ?x? means don't care. the tables overlap: for example, a code of 0110 indicates a slot which can be written in encrypted form using the write command and can also be the target of an unauthorized derivekey command with the target as the source. keytype in the keyconfig field (see table 2 - 7 ) indicates whether the genkey or derivekey co mmands can be used on a particular slot; with genkey for ecc keys only, and derivekey for sha - 256 keys. see section 2.2.10.4 , writing ecc private keys for special information regarding the writing of ecc private keys. ecc public keys are treated as normal data, and write permissions for those slots are described in this section. table 2 -7. write configuration bits: write command bit 15 bit 14 bit 13 bit 12 mode name description 0 0 0 0 always clear text writes are always permitted on this slot. slots set to always should never be used as key storage. either 4 or 32 bytes may be written to this slot. 0 0 0 1 pubinvalid if a validated public key is stored in the slot, writes are prohibited. use verify(invalidate) to invalidate prior to writing. do not use this mode unless slot contains a public key. see section 4.3 0 0 1 x never writes are never permitted on this slot using the write command. slots set to never can still be used as key storage. 1 0 x x never writes are never permitted on this slot using the write command. slots set to never can still be used as key storage. x 1 x x encrypt writes to this slot require a properly computed mac, and the input data must be encrypted by the system with writekey using the encryption algorithm documented in the write command description. 4 - byte writes to this slot are prohibited. ATECC608A - preliminary ?2017 microchip technology page 19 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 table 2 -8. write configuration bits: derivekey command bit 15 bit 14 bit 13 bit 12 source key (1) description 0 x 1 0 target derivekey command can be run without authorizing mac. (roll) 1 x 1 0 target authorizing mac required for derivekey command. (roll) 0 x 1 1 parent derivekey command can be run without authorizing mac. (create) 1 x 1 1 parent authorizing mac required for derivekey command. (create) x x 0 x slots with this value in the writeconfig field may not be used as the target of the derivekey command. note 1. the source key for the computation performed by the derivekey command can either be the key directly specified in param2 (target) or the key at slotconfig[param2].writekey (parent). the issecret bit controls internal circuitry necessary for proper security for slots in which reads and/or writes must be encrypted or are prohibited altogether. it must also be set for all slots that are to be used as keys, including those created or modified with the derivekey command. specifically, to enable proper device operation, this bit must be set unless writeconfig is always . a n exception is that the countermatch slot must have issecret set to 0, but may have any legal writeconfig value. four byte accesses are generally prohibited to and from slots in which this bit is set. slots used to store key values should always have issec ret set to one and encryptread set to zero (reads prohibited) for maximum security. for fixed key values, writeconfig should be set to never . when configured in this way, after the data zone is locked, there is no way to read or write the key; and it may o nly be used for crypto operations. some security policies require that secrets be updated from time to time. the ATECC608A supports this capability in the following way: writeconfig for the particular slot should be set to encrypt and slotconfig.writekey should point back to the same slot by setting writekey to the slot id. a standard write command can then be used to write a new value to this slot, provided that the authentication mac is computed using the old (i.e. current) key value. 2.2.10.4 writing ecc privat e keys ecc private keys are designated via the appropriate contents of keyconfig.keytype and keyconfig.pubinfo. they can never be written with the write and/or derivekey commands. instead, genkey and privwrite can be used to modify these slots. it is alway s an error to attempt to execute genkey or privwrite on a slot that is not configured to contain an ecc private key. slotconfig.writeconfig has the following interpretations for these commands: table 2 -9. write configuration bits: genkey command bit 15 bit 14 bit 13 bit 12 description x x 0 x genkey may not be used to write random keys into this slot. x x 1 x genkey may be used to write random keys into this slot. ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 20 ? 2017 microchip technology table 2 -10. write configuration bits: privwrite command bit 15 bit 14 bit 13 bit 12 mode name description x 0 x x forbidden privwrite will return an error if the target key slot has this value. x 1 x x encrypt writes to this slot require a properly computed mac and the input data must be encrypted by the system with slotconfig.writekey using the encryption algorithm documented in the privwrite command description. 2.2.11 keyconfig (bytes 96 thru 127) the 16 keyconfig elements are used in addition to slotconfig to restrict the actions that can be performed using information stored in a particular slot. the keyconfig element is interpreted according to the table below when the data zone is locked. when the data zone is unlocked, these restrictions do not apply, with the exception that slots configured to contain private keys can be written only with the privwrite command. table 2 -11. keyconfig bits (per slot) bit name description 0 private 1 = the key slot contains an ecc private key and can be accessed only with the sign , genkey , and privwrite commands. 0 = the key slot does not contain an ecc private key and cannot be accessed with the sign , genkey , and privwrite commands. it may contain an ecc public key, a sha key, or data. 1 pubinfo if private indicates this slot contains an ecc private key: 0 = the public version of this key can never be generated. use this mode for the highest security. 1 = the public version of this key can always be generated. if private indicates that this slot does not contain an ecc private key, then this bit may be used to control validity of public keys. if so configured, the verify command will only use a stored publ ic key to verify a signature if it has been validated. the sign and info commands are used to report the validity state. the public key validity feature is ignored by all other commands and applies only to slots 8 C 15. 0 = the public key in this slot can be used by the verify command without being validated. 1 = the public key in this slot can be used by the verify command only if the public key in the slot has been validated. when this slot is written for any reason, the most significant four bits of b yte 0 of block 0 will be set to 0xa to invalidate the slot. the verify command can be used to write those bits to 0x05 to validate the slot. if this slot contains a key of type data or aes, then the pubinfo bit controls whether or not the kdf command writ e data into this slot. if 1, then writes by kdf are allowed. if 0, kdf may not write to this slot. 2 ? 4 keytype if the slot contains an ecc public or private key, then the key type field below must be set to 4. if the slot contains any other kind of data, key, or secret, then this field must be set to another value for proper operation, as listed below. 0 - 3 = rfu (r eserved for future use) 4 = p256 nist ecc key 5 = rfu (reserved for future use) 6 = aes key 7 = sha key or other data ATECC608A - preliminary ?2017 microchip technology page 21 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 bit name description 5 lockable 1 = then this slot can be individually locked using the lock command. see the slotlocked field in the configuration zone to determine whether a slot is currently locked or not. 0 = then the remaining keyconfig and slotconfig bits control modification permission. applies to all slots, regardless of whether or not they contain keys. see section 2.4 , eeprom locking . 6 reqrandom this field controls the requirements for random nonces used by the following commands: genkey , mac , checkmac , verify , derivekey , and gendig . 1 = a random nonce is required. 0 = a random nonce is not required. 7 reqauth 1 = before this key must be used, a prior authorization using the key pointed to by authkey must be completed successfully prior to cryptographic use of the key. applies to all key types, both public, secret, and private. see section 4.4.8 , authorized keys . 0 = no prior authorization is required. 8 ? 11 authkey if reqauth is one, this field points to the key that must be used for authorization before the key associated with this slot may be used. must be zero if reqauth is zero. 12 persistentdisable 1 = use of this key is prohibited for all commands other than genkey if the persistentlatch is zero. genkey is permitted regardless of the state of the latch. 0 = then use of this key is independent of the state of the persistentlatch. 13 rfu must be zero. 14 ? 15 x509id the index into the x509format array within the configuration zone (addresses 92 - 95) which corresponds to this slot. if the corresponding format byte is zero, then the public key can be validated by any format signature by the parent. if the corresponding format byte is non - zero, then the validating certificate must be of a certain length; the stored public key must be located at a certain place within the message and the sha() commands must be used to generate the digest of the message. must be zero if t he slot does not contain a public key. (1) more information on select fields is described below. ? private this bit indicates that the slot contains an ecc private key and it is used by the device to limit uses of this slot to the appropriate ecc command s. if this bit is set, then slotconfig.readkey is used to enable or disable the use of the private key for various operations. readkey:0 enables the use of the key for signatures of externally supplied data, while readkey:1 enables the use of the key to si gn only messages that are stored in tempkey by the genkey or gendig commands. this mechanism permits a remote entity to have the knowledge that a particular key value or slot contents are stored within an ATECC608A device, and it prevents an attacker from creating an external message that would model an internal state that does not exist and create a signature of that state. ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 22 ? 2017 microchip technology ? pubinfo for public keys, this field can be used to walk a certificate chain to validate the key. this feature is implemented using the verify command and the validation is stored in nonvolatile memory alongside the key so that subsequent uses of the public key do not require additional validation. these keys are always invalidated when any part of the slot containing the key is written. for private keys, this field can be used to increase security or privacy in some situations by preventing the generation of the pu blic key corresponding to a private key. the presumption is that the public key has been stored elsewhere at the time the private key was generated or written into the device. this field is ignored when a random key is generated. the ATECC608A includes a m ethod of walking either an x.509 certificate chain or a simplified internal format chain. see the sha and verify(validateexternal) commands for more details. if keytype is data or aes, then pubinfo controls whether or not the kdf command may write data int o this slot. if 1, then writes by kdf are allowed, if 0, kdf writes are not permitted. ? keytype the four ecc commands that use ecc keys (i.e. genkey , sign, ecdh, and verify ) will operate only on data slots in which this field is set to one of the legal ecc key types. any attempt to use any symmetric computation commands (i.e. checkmac , derivekey , mac , or aes ) on a slot configured to be an ecc private key will result in an error. keys that will be the source or destination of the symmetric computation comman ds should be set to a keytype of 6 (aes) or 7 (data) as appropriate. proper operation of the device is not guaranteed if these commands are attempted with any other keytype. the gendig command may operate on any slot type other than for ecc private keys. ? reqrandom this field is useful in preventing replays of authorization and/or other cryptographic operations. keys that control encrypted reads and/or writes should have this field set to one under normal circumstances in order to provide data security. i f this field is set to one, then prior to the execution of the checkmac, gendig, derivekey , verify and mac commands, the random number generator (rng) must have been used by the nonce command to generate the contents of tempkey. if genkey is used to gener ate a public key digest of either a public or private key stored in a data zone slot, then the reqrandom field is used to ensure that the nonce in tempkey included the rng. ? reqauth if this bit is set, then prior authorization of the key at keyconfig.aut hkey must have been completed prior to execution of any cryptographic command (i.e. checkmac , derivekey , gendig , genkey , mac , sign , or verify ) that uses this key. the derivekey command checks for usage authorization only for the parent key, and never the t arget key, unless it is the same as the parent key. the genkey command checks for usage authorization even when generating a new key to prevent denial of service attacks. the authorization state is stored in two internal volatile registers: ? authcomplete. valid ? authcomplete.keyid these registers are retained as long as power is applied, and the device does not enter the sleep mode. these registers are set by means of the execution of a successful checkmac or verify command with the key to be authorized as the target key of the command. checkmac must be run with mode:1 set to one, or verify must be run in stored mode to set authcomplete.valid. authcomplete.keyid is set to the value in the ATECC608A - preliminary ?2017 microchip technology page 23 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 keyid parameter to these commands. the checkmac and verify commands do not clear these bits on an unsuccessful authorization attempt unless the keys also happen to be used as the source key. authcomplete.valid is cleared under the following situations: ? the device enters sleep mode or power is removed. ? any command is executed that uses a key requiring prior authorization, regardless of which slot has been authorized and/or which slot was required to be authorized for this key. if there are multiple state or configuration errors preventing the proper execution of the command, t hen authcomplete.valid may or may not be cleared depending upon the specific error conditions encountered. 2.3 eeprom one time programmable (otp) zone the otp zone of 64 bytes (512 bits) is part of the eeprom array and can be used for read - only storage. it is organized as two blocks of 32 bytes each. the data cannot be modified and is normally used to store fixed model numbers, calibration information, manufacturing history, or other data that should never change. prior to locking the configuration zone (by usi ng lockconfig), the otp zone is inaccessible and can be neither read nor written. after configuration locking, but prior to locking of the otp zone (using lockvalue), the entire otp zone can be written using the write command. prior to locking the data/otp zones using lockvalue, this zone cannot be read at all. once the otp zone is locked, the contents can always be read but never written. attempts to use the write command will always return an error and leave the memory unmodified. all 64 bytes within the otp zone are always available for reading using either 4 or 32 byte reads. all otp bits have a value of one upon shipment from the microchip factory. 2.4 eeprom locking there are two separate lock states for the device: ? one to lock the configuration zone (that is controlled by lockconfig, byte 87). ? one to lock both the otp and data zones (that are controlled by lockvalue, byte 86). these locks are stored within separate bytes in the configuration zone, and they can be modified only by means of the lock co mmand. after a memory zone is locked, there is no way to unlock it. both bytes are set to 0x55 (unlocked) on shipment from microchip in addition to the two device locking options described above, there is an individual slot locking mechanism that can optio nally be configured for every slot. this locking operation can take place at any time before or after the chip locking operations have occurred. the device should be personalized at the system manufacturer?s site with the desired configuration information; after which, the configuration zone should be locked. then, all necessary writes of public and secret information into the data and otp zones should be performed by using encrypted writes, if appropriate, and then the data and otp zones should be locked. it is vital that the data and otp zones be locked prior to release into the field of the system containing the device. failure to lock these zones may permit modification of any secret keys and may lead to other security problems. any attempt to read or write the data or otp zones prior to locking the configuration zone causes the device to return an error. contact microchip for optional secure personalization services. ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 24 ? 2017 microchip technology 2.4.1 configuration zone locking certain bytes within the configuration zone can never be modified in the field regardless of the lock status, per table table 2 - 4 . write permission for most of the remaining bytes within the zone is cont rolled using the lockconfig byte in the configuration zone as shown in the table below. throughout this document, if lockconfig is 0x55 , the configuration zone is said to be unlocked; otherwise, it is locked. table 2 -12. configuration zone locking read access write access lockconfig == 0x55 (unlocked) read write lockconfig != 0x55 (locked) always ATECC608A - preliminary ?2017 microchip technology page 25 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 modification of that slot via the privwrite , write , genkey , and/or derivekey commands is permanently prohibited, regardless of the sta te of the corresponding lockable, slotconfig and/or keyconfig bits. when slotlocked is zero, then the corresponding slot cannot be written even if the data zone is unlocked. ? lockable bits after the configuration zone is locked, the state of the lockable bit for a particular slot controls whether or not the lock command will be permitted to change the slotlocked bit for the corresponding slot, per the table below. if lockable is one, then the lock command can be used to modify the slotlocked bit either bef ore or after the data zone is locked. table 2 -15. individual slot locking after configuration zone is locked slotlocked bit lockable bit lock command privwrite , write , derivekey , ecdh, kdf and genkey commands notes 0 0 or 1 no no not writeable. 1 0 no yes writeable but not lockable. 1 1 yes yes writeable and lockable. individually lockable slots can contain either secret information or readable data and may be used in one of two ways: ? the configuration zone and non - lockable data slots should be initialized and locked in the usual manner by the oem. after the data zone has been locked, those particular slots marked as lockable can then be modified and individually locked in the field at some point in the future. ? after the configuration zone is locked, some slots can be personalized and locked by the oem prior to transfer of the device/component to a second party such as a subcontractor or distributor that personalizes the remaining slots , and then locks the data zone prior to shipment of the device into the field. the lock command does not provide a crc validation mechanism when using the individual slot locking mechanism. if slots are locked prior to locking of the entire data zone, then the contents may be validated at the time of data/otp locking. after the data zone is locked, either the read, checkmac , or mac commands can be used to validate the slot contents prior to individual slot locking. validation of a public key via the verify command can occur regardless of the state of the slotlocked bit for that slot. ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 26 ? 2017 microchip technology 3 static ram (sram) memory the device also includes an sram array that is used to store the input command or output result, nonces, intermediate computation values, ephemeral keys, the sha context, etc.. the entire contents of this memory are always invalidated whenever the device g oes into sleep mode or the power is removed. 3.1 tempkey tempkey is the primary storage register in the sram array that can be used to store various intermediate values. the contents of this register can never be read from the device (although the device itse lf can read and use the contents internally). tempkey is 64 bytes long. the kdf and nonce commands are capable of writing both 32 byte halves of this register, all other commands can modify only the first (lower) 32 bytes of tempkey. either the first 32 by tes or all 64 bytes can be valid, the device does not permit the upper 32 bytes to be valid if the lower 32 bytes are invalid. along with the data portion of the tempkey register is a set of flags that indicate information about the source of the data and also its validity. the info command can be used to return the value of some of the status/flag bits corresponding to this register as below: table 3 -1. tempkey flags name length description keyid 4 bits if tempkey was generated by gendig or genkey , these bits indicate which key was used in its computation. the four bits represent one of the slots of the data zone. sourceflag 1 bit the source of the randomness in tempkey: 0 = internally generated random number ( rand ). 1 = input (fixed) data only, no internal random generation ( input ). generator 4 bit 0 = tempkey was not generated by gendig . 1 = the contents of tempkey were generated by gendig using one of the slots in the data zone (and tempkey.keyid will be meaningful). genkeydata 1 bit 0 = tempkey.keyid was not generated by genkey . 1 = the contents of tempkey were generated by genkey using one of the slots in the data zone (and tempkey.keyid will be meaningful). nomacflag 1 bit 1 = the contents of tempkey were generated using the value in a slot for which slotconfig.nomac is one, and therefore cannot be used by the mac command. if multiple slots were used in the calculation of tempkey, then this bit will be set if slotconfig.nomac was set for any of those slots. valid 1 bit 0 = the information in tempkey is invalid. 1 = the information in tempkey is valid. in this specification, these flags are generally referred to as tempkey.sourceflag, tempkey.gendigdata, and so forth. when tempkey.valid is 0, then any attempted use of the tempkey register contents will result in an error, regardless of the state of any other flag bits. the tempkey resigster and all its flags are cleared to zero during power - up, sleep, brown - out, watchdog exp iration or tamper detection. the contents of tempkey and the flags are retained when the device enters idle mode. in general, tempkey.valid and all the other flags are cleared to zero whenever tempkey is used (read) for any purpose during command executio n. when a command that is intended to use tempkey encounters an error, ATECC608A - preliminary ?2017 microchip technology page 27 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 tempkey may or may not be cleared depending on the situation. if a particular command or command mode/configuration does not use tempkey then it will never be cleared. tempkey is never cleared by the kdf or aes commands. commands which leave a result in tempkey will set the valid flag and any other flags which may be appropriate for the operation performed. 3.2 message digest buffer the message digest buffer is a 64 byte register that is use d to convey the input message digest to the verify and sign commands when the tempkey register is needed to retain different information. the sha command can write a digest directly to this register to simplify external host programming. if a validating ma c is desired with the output of the verify command, this register is always used to convey the nonce used to compute that mac. the location of the nonce within the message digest buffer depends on whether the signature message digest is being input via tem pkey or the message digest buffer. the nonce command can write either 32 or 64 bytes of fixed input data to the message digest buffer. the message digest buffer is generally cleared after the execution of most commands with the exception of the nonce and s ha commands. it can only be used (read) in a single command without reloading as it is always cleared upon use. 3.3 alternate key buffer the alternate key buffer is a 32 byte register that can be used by the kdf command to store keys when the tempkey register is needed to retain different information. it can be written to a fixed input value by the nonce command or to a secret value by the kdf command. the alternate key buffer is cleared on power - up or wake from sleep and otherwise remains valid once written. a use for the alternate key buffer is to generate two separate sram - based keys from a single root key. one method to accomplish this is to use the kdf command with the input set to the altkeybuf and the output set to tempkey(lo). then the kdf is run a secon d time with the output set to tempkey(hi), resulting in two distinct keys being stored in one location, in this case tempkey. a flow similar to this may be required for tls 1.3. 3.4 sha context buffer the sha command uses a standard three phase flow: initialize, update and finalize. in many situations the update phase is run many times. internal sram memory is used to store the intermediate state, aka sha context, between these phases. this sha context buffer is neither read nor written by any other at ecc608a command and is therefore not disrupted regardless of the success or failure of the execution of any other commands. like all sram memory in the device, it is cleared when the device goes to sleep or power is removed. 3.5 persistent latch the ATECC608A has a single volatile memory bit known as the persistent latch that retains its state as long as vcc remains above 2.0v. it is always set to zero on power - up and may be manipulated using the operations described below. the current state of the persistent l atch can always be read via the info(mode=4) command, regardless of the way in which its use is configured. note that this bit is not stored in the sram which loses its state when the device goes into sleep mode. depending on the way the configuration zone is coded, this latch may have several different functions: ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 28 ? 2017 microchip technology volatile key usage permission : when configured in this mode, the state of the persistent latch is used to enable or disable key slots that have been so configured. the state of the latch can be wr itten to either a 1 or 0 using the info(mode=4) command. see section 2.2.5 for more details. secure boot : this mode is similar to the previous, in that key slots are enabled or disabled with the state of the persistent latch, but the latch is set by the secureboot c ommand instead of the info command. authorization output : when configured in this mode, the persistent latch is used to store the value to which the scl is being driven. the state of the latch can be changed using the info(mode=3) command with proper autho rization via config.gpiocontrol.signalkey. one use for this function is to securely enable or disable external hardware based on some sequence that would run in the host on startup. intrusion detection : when configured in this mode, the state of the persis tent latch reflects whether the scl pin has been pulled low at any time during this power cycle. one use for this is to connect to an external tamper switch that detects unauthorized opening of the system case, maintenance door, etc. a typical implementati on would connect a battery to vcc and scl through the switch such that scl goes to 0v when the switch is open or the tamper wires are broken. the state of the latch can be initially ?armed? via the info(mode=3) command with proper authorization via config. gpiocontrol.signalkey. keys would be enabled/disabled with this state. generally, if the device is configured for more than one of these uses then the behavior may be different than expected. both volatile key usage permission and secure boot modes may be configured to affect the persistent latch, however enablement of the keys will no longer be dependent only on a proper secure boot. a careful security analysis of the system must be undertaken in this situation including protection of the volatilepermissio n key value held in the host system. ATECC608A - preliminary ?2017 microchip technology page 29 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 4 security information 4.1 cryptographic standards the ATECC608A follows various industry standards for the computation of cryptographic results. these reference documents are described in the sections below. 4.1.1 sha - 256 the at ecc608a computes the sha - 256 digest based upon the algorithm documented in the following site: http://nvlpubs.nist.gov/nistpubs/fips/nist.fips.180 - 4.pdf the complete sha - 256 message processed by the ATECC608A is listed in section 10 , for each of the particular commands that use the algorithm. most standard software implementat ions of the algorithm automatically add the appropriate number of pad and length bits to this message to match the operation the device performs internally. the sha - 256 algorithm is also used for encryption by taking the output digest of the hash algorithm and xoring it with the plain text data to produce the ciphertext. decryption is the reverse operation, in which the ciphertext is xored with the digest with the result being the plain text. 4.1.2 hmac/sha - 256 the ATECC608A can compute an hmac digest based upon sha - 256 using a key stored in the eeprom as documented below: http://csrc.nist.gov/publications/fips/fips198 - 1/fips - 198 - 1_final.pdf 4.1.3 tls v1.2 pseudo random function (prf ) the ATECC608A kdf(prf) command calculates the key derivation function (kdf) specified for tlsv1.2 (and earlier) at: https://tools.ietf.org/html/rfc5246 4.1.4 hmac - based extract - and - expand kdf (hkdf) the ATECC608A kdf(hkdf) command calculates the hkdf key derivation function (kdf) . this is the kdf currently planned to be used in the tls1.3 proposal. it is specified at: https://tools.ietf.org/html/rfc5869 4.1.5 elliptic curve digital signature algorithm (ecdsa) the ATECC608A computes and verifies the elliptic curve signatures according to the algorithm documented in: ansi x9 .62 - 2005 http://www.ansi.org/ fips 186 - 4 specification http://nvlpubs.nist.gov/nistpubs/fips/nist.fips.186 - 4.pdf ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 30 ? 2017 microchip technology 4.1.6 elliptic curve diffie - hellman ( ecdh) the ATECC608A executes the ecdh key agreement according to nist special publication 800 - 56a recommendations: http://nvlpubs.nist.gov/nistpubs/specialpublicatio ns/nist.sp.800 - 56ar2.pdf for the purposes of compliance to 800 - 56ar2, the ATECC608A always treats the input public key as an ephemeral key. for optimal security, no private key should be used for both ecdsa and ecdh. this restriction can be implemented by properly setting the bits within slotconfig[keyid].readkey. 4.1.7 advanced encryption standard (aes) symmetric encryption & decryption, if enabled, is implemented via the aes command using only aes - 128 per: http://csrc.nist.gov/publications/fips/fips197/fips - 197.pdf 4.2 secure boot the ATECC608A provides a mechanism to support secure boot operations in a connected mcu, which can help to identify situations in which fraudulent code has been installed on the host cpu. on power - up, the boot code within the host mcu sends the code digest and appropriate signature to the ATECC608A. if the signature validates that digest using the pre - approved code validating public key stored in the ATECC608A, t hen a message is returned to the host mcu indicating success. identity and communication keys can optionally be configured to be disabled on power - up. in the event of a secure boot successful validation, these keys will be enabled for use. the state of the secure boot result is stored in a special latch that does not lose its value even when the ATECC608A is put to sleep so that the secure boot operation does not need to be re - run unless power is removed from the ATECC608A. it is expected that the same powe r rail will be used to supply both the host mcu and the ATECC608A. if the secure boot validation fails, then the id/comm keys will remain disabled until a successful digest/signature pair is sent to the ATECC608A. the public key used to validate the signa ture of the code digest is stored in the slot indicated by config.secureboot.securebootpubkey. generally, slotconfig.writeconfig for this slot should be set to never, as the code signing key is rarely intended to change. if it is desired that the system ha ve the ability to update the secure boot public key, then writeconfig for that slot should be set to pubinvalid (0001) and the public key update mechanism described in section 4.3 should be employed. if the code to be validated at boot is relatively small, then the sha computation engine on the ATECC608A can be used to calculate the code digest by sending the code bytes to the ATECC608A. for many systems this may be too slow, however in some hierarchical boot cases the primary boot code itself can be optimized sufficiently that its size permits use of the ATECC608A. 4.2.1 secure boot speed optimization the ATECC608A secureboot command includes the option to store the signature and/or digest within the protected boundary of the ATECC608A to reduce the execution time. the signature and/or digest can be updated via a mode switch on the normal secure boot command which performs both a verify of the signature and storage of the signature/digest in a designated slot. storing the signature reduces the boot time by limiting the size of the io block that needs to be sent to the ATECC608A from 96 bytes to only 32 bytes. if the digest is stored, then the ATECC608A d oes only a digest compare between the host code digest in the input array and the stored digest in a slot of the ATECC608A. this reduces the boot time by eliminating the computation delay for the ecc verification. ATECC608A - preliminary ?2017 microchip technology page 31 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 the securebootsigdig slot configuration mu st be set up to ensure that only the secureboot command has the capability to write into the designated storage slot: ? the target slot (config.secureboot.sigdig) must not be locked via the slotlocked capability ? write config for the target slot (config.slotc onfig.writeconfig) should generally be set to ?never? to avoud situations in which fraudulent modification of the slot may be possible ? if the device is configured to store the signature then the designated slot must be from 8 - 15. digests can be stored in a ny slot 4.2.2 secure boot wire protection in some applications, it may be necessary to protect the system against an adversary who might cut the wire(s) between the ATECC608A and the host mcu to replace the result of the verify operation with a fraudulent ?succe ss? signal. if so configured or indicated by the mode parameter to the secure boot command, the input code digest can be encrypted via and xor of the code digest with a digest of a nonce and the io protection secret. the config.secureboot.securebootrandnon ce bit can be used to ensure that this input encryption is always performed and that it uses a nonce generated by the ATECC608A random number. such a flow prevents the replay of a message from an earlier point in time from being used as input to the atecc6 08a secureboot command. if so configured or indicated by the mode parameter to the secure boot command, the output boolean can be accompanied by a mac generated over an input nonce from the host and the io protection key. generally, the host nonce would be generated by a counter or random number generator on the mcu, its only requirement is that it be unique vs other secure boot nonces. these two functions: mac - protected enablement of specified key slots and mac validation of the ecc verify output are avail able separately in the volatile key permit function (see section 2.2.5 ) and the verify command mac output if the secure boot command is not used. in addition to prevention of man - in - the - middle attacks, these sequences prevent the ATECC608A from being removed off of one board and used on another or in some other kind of system since the new board would not contain the io protection secret contained on the mcu of the initial board. while it is expected that with some effort an attacker could extract the io protection secret from the mcu, that process would have to be repeated again for every board attacked. 4.3 public key update keys used to validate code di gest or chain of trust roots can be stored on the ATECC608A. using the device for this storage can prevent some kinds of attacks because rogue software cannot overwrite the public key with a fraudulent key. generally, these root public keys are stored in a slot and the slotconfig.writeconfig field is set to never. in this case, there is no method for any software to write the public key slot. however, in some environments there may be a requirement to be able to update the root key in the hopefully unlikely event that the corresponding private key is compromised. the basic flow for public key update is as follows: 1) use the parent key to sign the appropriate message to verify(invalidate) to clear the validation bits on the root public key. 2) use the write command to write a new root public key to the root public key slot, it will be still marked as invalid and cannot yet be used. 3) use the parent key to sign the appropriate message to verify(validate) to set the validation bits on the root public key and a llow for normal use. the two key slots should be configured as follows: ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 32 ? 2017 microchip technology ? the root public key should be stored in a slot with slotconfig.writeconfig set to ?pubinvalid? (0001). keyconfig.keytype should be set to p256 (4). keyconfig.pubinfo should be set to 1 . keyconfig.x509id should point to one of the config.x508format bytes that has a value of 0. slotconfig.readkey should point to a parent public key. ? the parent public key slot should have slotconfig.writeconfig set to never, keyconfig.keytype should be set to p256 (4) and keyconfig.pubinfo should be set to 0. if keyconfig.reqrandom is set on the parent slot, then the update sequence will be required to use the rng on the ATECC608A, thereby preventing an update package that works on one device from working o n another. if reqrandom is zero, then a common update sequence can be used for multiple ATECC608A devices. this flow is protected against a destructive rogue write (denial of service) because in order to do the write a signature is required from the parent key. under normal circumstances, such a signature would never exist and the write would never be possible. 4.4 key uses and restrictions any slot in the eeprom data zone can be used to store a secret or private key. there are a number of ways in which the key s stored within the device can be used and/or their access restricted. see the following sections 4.4.1 , dive rsified keys to 4.4.8 , diversified keys for some of these concepts. the device should be properly configured to prevent any unwanted read and write access to all key slots, including the setting of the issecret bit. private keys can never be read from the device regardless of the values in the configuration zone. with the exception of transport keys documented in section 4.4.7 , transport keys , the most significant 12 bits of all keyid parameters should be zero. 4.4.1 diversified keys if the host or validating entity has a place to securely store secrets, or contains an ATECC608A device, the secret key val ues stored in the eeprom slot(s) of the clients can be diversified by using the serial number embedded in the device (sn[0:8]). in this manner, every client device can have a unique key, which can provide extra protection against known plaintext attacks an d permit compromised serial numbers to be identified and blacklisted. to implement this operation, a root secret is externally combined with the device?s serial number during personalization by using some cryptographic algorithm, and the result is written to the ATECC608A key slot. the ATECC608A gendig and checkmac commands provide a mechanism to securely generate and compare diversified keys, thereby eliminating this requirement from the host system. consult the following application note for more detail s: http://www.atmel.com/dyn/resources/prod_documents/doc8666.pdf 4.4.2 rolled keys in order to prevent repeated uses of the same secret key value, the ATECC608A supports key rolling. normally, after a certain number of uses (perhaps as few as one), the current key value is replaced with the sha - 256 digest of its current value combined with some offset, which may either be a constant, something related to the current system (for example , a serial number or model number), or a random number. this capability is implemented using the derivekey command. prior to execution of the derivekey command, the nonce command must be run to load the offset into tempkey. one use for this capability is to permanently remove the original key from the device, and replace it with a key that is only useful in a particular environment. after the key is rolled, there is no possible way to retrieve the old key?s value, which improves the security of the system. ATECC608A - preliminary ?2017 microchip technology page 33 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 any power interruption during the execution of the derivekey command in roll mode may cause the key to have an unknown value. if writing to a slot is enabled using bit 14 of slotconfig, such keys can be written in encrypted and authenticated form using t he write command. alternatively, multiple copies of the key can be stored in multiple slots so that failure of a single slot does not incapacitate the system. 4.4.3 created ecc keys for the highest security, private ecc keys may be created within the ATECC608A using the internal high quality rng. when a key is generated internally, the public portion of the key is always returned to the system. the generated key may be either stored in an eeprom slot or held in tempkey for later use by the ecdh command. for priv ate keys stored in an eeprom slot, the public key can optionally be computed from the private key if the slot is so configured. internally generated keys are guaranteed to be unique to this device since there is no mechanism for reading the value of an ecc private key from the ATECC608A. 4.4.4 created secret keys there may be a need to have unique ephemeral symmetric keys on each client; a function also supported by the ATECC608A. with this mechanism, a parent key (that is specified by slotconfig.writekey) is com bined with a fixed or random nonce to create a unique key, which is then used for any cryptographic purpose. the ability to create unique keys is especially useful if the parent key has usage restrictions (see section 4.4.5 , below). in this mode, the limited use parent can be employed to create an unlimited use child key. because the child key is useful only for this particular host - client pair, atta cks on its value are less valuable. this capability is also implemented using the derivekey command. prior to execution of the derivekey command, the nonce command must be run to load the nonce value into tempkey. 4.4.5 high endurance monotonic counters the ate cc608a supports two independent high endurance nonvolatile monotonic counters that can count to a value of 2,097,151. their value never decreases and the storage elements are protected against count loss if the power is interrupted during an incrementing o peration. the current value of the two counters can be read using the counter command, which can also be used to increment the counters. there is no way to reset the counters. the counters can be used in one of two methods: ? cryptographic counters : in this mode, the counter command is used to increment the value of the counters and the current value can be read via the same command. the two counters are independent. ? limited key use : counter[0] can be attached to any key via the slotconfig.limiteduse bit. i f this bit is set for any particular key, then any use of the key will cause the counter to increment automatically prior to the operation being performed. if the counter has reached its limit, then the command will return an error code, and no counter cha nge will occur. see microchip for alternate limit programming. the genkey, read , and write commands ignore the monotonic counter limited use feature. it is also ignored for the copied slot during checkmac(copy) . 4.4.6 password checking many applications require a user to enter a password to enable features, decrypt stored data, or perform some other task. typically, the expected password has to be stored somewhere in the memory, and therefore is subject to discovery. the ATECC608A can securely store the expected password and perform a number of useful ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 34 ? 2017 microchip technology operations upon it. the password is never passed in the clear to the device, and it cannot be read from the device. it is hashed with a random number in the system software before being passed to the device. the copy capability of the checkmac command enables the following types of password checking options: 1. checkmac does an internal comparison with the expected password and returns a boolean result to the system to indicate whether the password was correctly entered or not. 2. if the device determines that the correct password has been entered, then the value of the password can optionally be combined with a stored ephemeral value to create a key that can be used by the system for data protection purposes. 3. if the device determines that the correct password has been entered, then the device can use this fact to optionally release a secondary high entropy secret, which can be used for data protection without the risk of an exhaustive dictionary attack. 4. if the password has b een lost, then an entity with knowledge of a parent key value can optionally write a new password into the slot. optionally, the current value can be encrypted with a parent key and read from the device. to prepare for this checkmac/copy capability, passwo rds should be stored in even numbered slots. if the password is to be mapped to a secondary value (using the third option above), then the target slot containing this value is located in the next higher slot number (i.e. the password?s slot number plus one ); otherwise, the target slot is the same as the password slot. readkey for the target slot must be set to zero to enable this capability. in order to prevent fraudulent or unintended usage of this capability, do not set readkey for any slot to zero unless this checkmac/copy capability is specifically required. in particular, do not assume that the other bits in the configuration word for a particular slot will override the enablement of this capability specified by readkey = 0. this capability is only ena bled if the mode parameter to checkmac has a value of 0x01 , indicating the following: ? the first 32 bytes of the sha - 256 message are stored in a data slot in the eeprom (i.e. the password). ? the second 32 bytes of the sha - 256 message must be a randomly generated nonce in the tempkey register. if the above conditions are met, and the input response matches the internally generated digest, then the contents of the target key are copied to tempke y. the other tempkey register bits are set as follows: ? sourceflag is set to one (not random). ? gendigdata is set to zero (not generate by the gendigdata command). ? nomacflag is set to zero (tempkey is usable by mac and read commands). ? valid is set to one. see the microchip website for application notes with more details on this capability. 4.4.7 transport keys the ATECC608A device includes an internal hardware array of keys that are used for secure personalization (i.e. transport keys). the values of the hardware keys are kept secret and are made available only to qualified customers upon request to microchip . these keys can be used with the gendig command only and are indicated by a keyid value greater than or equal to 0x8000. for gendig and all other commands, k eyid values of less than 0x8000 always reference keys that are stored in the data zone of the eeprom. in these cases, only the four least - significant bits of keyid are used to determine the slot number, while the entire 16 bit keyid as input is used in any sha - 256 message calculation. ATECC608A - preliminary ?2017 microchip technology page 35 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 4.4.8 authorized keys the ATECC608A device provides an optional mechanism for restricting the use of any key to those users with knowledge of the appropriate authorization information. key authorization is a standard cryptographic r equirement in many systems and can be used to prevent fraudulent use of a key if the device containing the key is stolen or lost. for instance, if a key is used as identification for a person, the authorizing value could be a password known only to that pe rson. if the device with the id is stolen, then the thief cannot use the device to sign fraudulent messages since he or she does not know the password. the device can use either the checkmac or verify commands to implement this capability. if the validatio n succeeds, then an internal authcomplete flag is set and the authorizing slot number is retained. the authcomplete flag is cleared whenever the device wakes from sleep or is powered on. it is also cleared when any operation is performed on a key which req uires authorization. prior to the authorization check, the nonce command must be run to load tempkey with a nonce. ? checkmac the authorization value is stored in any slot configured to contain a secret, and it is validated with a mac calculated using that secret and the nonce stored in tempkey. ? verify the authorizing slot must contain a valid ecc public key. the authorization value should be a signature calculated using the corresponding private key calculated over the nonce stored in tempkey. this signatur e is then validated. depending upon the configuration of the slot containing the authorizing secret, a token can be externally stored, which can be repeatedly used for key authorization. if the authorizing slot is configured to require a random nonce (keyc onfig.reqrandom is one), then a stored authorizing token will not work, and the authorizing digest or signature will have to be computed on the fly by the authorizing agent using the random nonce generated by the device. 4.5 security features 4.5.1 physical security the ATECC608A incorporates a number of physical security features designed to protect the eeprom contents from unauthorized exposure. among many others, these security measures include: ? active shield circuitry ? internal memory encryption ? glitch protection ? voltage and temperature tamper detection pre - programmed transport keys stored on the ATECC608A are encrypted in such a way as to make retrieval of their values using outside analysis very difficult. both the logic clock and logic supply voltage are inte rnally generated, thus preventing any direct attack on these two signals using the pins of the device. 4.5.2 random number generator (rng) the ATECC608A includes a high quality cryptographic random number generator implemented using a combination of a non - deterministic noise (entropy) source (nrbg) seeding a deterministic algorithm (drbg) implemented according to the following nist standards. the nrbg is used both in the instantiation and each time an rng number is required. ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 36 ? 2017 microchip technology the nrbg output is evaluated using the methods in nist sp 800 - 90b. the drbg is designed using the aes - 128 variant specified within nist sp 800 - 90a. the combination of the two to create the final random number generator follows the methods specified in nist sp 800 - 90c. http://csrc.nist.gov/groups/stm/cavp/documents/drbg/drbgvs.pdf (sp 800 - 90a) http://csrc.nist.gov/publications/drafts/800 - 90/draft - sp800 - 90b.pdf http://csrc.nist.gov/publications/drafts/800 - 90/sp800_90c_second_draft.pdf the noise source runs continuously when power is applied to the chip unless the chip enters sleep mode. when a random number is requested the following two conditions are met prior to use of the random number: ? health testing is applied to the output of the noise source per sp 8 00- 90b to ensure that this particular noise source is working properly at the current time under the current environmental conditions. ? if insufficient entropy has been stored within ATECC608A, it will delay for sufficient time to accumulate the required en tropy. see http://csrc.nist.gov/groups/stm/cavp/documents/drbg/drbgval.html for further documentation on nist cavp certification of this rng. note that as of the time of this document, only sp - 800 - 90a has been released, both 800 - 90b and 800 - 90c are in various draft stages. the system may use this rng for any purpose. the device provides a special random command for such purposes that does not affect any ephemeral nonce that ma y currently be stored in one of the sram registers. to simplify system testing, prior to config locking the rng always returns the following value: ff ff 00 00 ff ff 00 00 ? where ff is the first byte read from the device and the first byte into the sha message. ATECC608A - preliminary ?2017 microchip technology page 37 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 5 general i/o information communications to the ATECC608A are through one of two different protocols. the protocols are selected by specifying the part number that is ordered: ? single - wire interface uses a single gpio connection on the system micr oprocessor that is connected to the sda pin on the device. it permits the fewest number of pins connected to any removable or replaceable entity. the bit rate is up to 26kb/s. ? i 2 c interface this mode is compatible with the i 2 c standard and also with the m icrochip at24c16 serial eeprom interface. two pins, serial data (sda) and serial clock (scl), are required. the i 2 c interface supports a bit rate of up to 1mb/s. the ATECC608A and at24c16b have different default i 2 c addresses. the ATECC608A i 2 c address can be modified from default by writing a new value into the configuration zone . the device implements a failsafe internal watchdog timer that forces it into a very low - power mode after a certain time interval regardless of any current activity. system programming must take this into consideration. see section 10.6 , watchdog failsafe . 5.1 byte and bit ordering cryptoauthentication uses a common ordering scheme for bytes and also for the way in which numbers and arrays are represented in this datasheet: ? all multi - byte aggregate elements are treated as arrays of bytes and are processed in the order received or transmitted with index #0 first. ? 16 b it (2 byte) integers, typically param2, slotconfig or keyconfig, appear on the bus least - significant byte first. ? ecc keys appear on the bus, and are stored in eeprom, with the most significant 32 - bit word at the lowest address. see section 5.1.1 , ecc key formatting for further information on ecc key formatting. in this document, the most - significant bit or nibble of a byte or 16 bit word appears tow ards the left hand side of the page. the bit order is different depending upon the i/o channel used: ? on the one - wire bus, data is transferred to and from the ATECC608A least significant bit (lsb) first on the bus. ? on the i 2 c interface, data is transferred to and from the ATECC608A most significant bit (msb) first on the bus. 5.1.1 ecc key formatting the format for public and private keys depends on the command and key length. in general, the most significant bytes (msb) appear fi rst on the bus and at the lowest address in memory. in the remainder of this section below, the bytes on the left side of the page are the msbs. atmel recommends all pad bytes be set to zero for consistency. ? ecc private keys appear to the user only as the input parameter to the privwrite command. this parameter is always 36 bytes in length and the first four bytes (32 bits) are all pad bits. ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 38 ? 2017 microchip technology ecc public keys appear as the input or output parameters to several commands, and they can also be stored in eeprom. they are composed of an x value first on the bus or in memory, followed by a y value. they are formatted differently depending upon the situation as noted below: ? the public key is an output of genkey command or an input to verify command : 32 bytes of x, t hen 32 bytes of y. (36 bytes) there are no pad bytes. ? write command : public keys can be written directly to the eeprom using write command and are always 72 bytes long, formatted as follows: 4 pad bytes, 32 bytes of x, four pad bytes, then 32 bytes of y. ? genkey command : sha message: public keys can be hashed and placed in tempkey by the genkey command. the sha message contains various bytes that are independent of the size of the key. these are followed by 25 bytes of pad, followed by 32 bytes of x, then 32 bytes of y. ? verify command : sha message: when used to validate a stored public key, the verify command expects an input signature created over a sha - 256 digest of a key stored in memory. such an inner sha calculation is always performed over 72 bytes fo rmatted as they are stored in eeprom as 4 pad bytes, 32 bytes of x, four pad bytes, then 32 bytes of y. when a public key is configured to be validated by the verify command, then the most significant four bits of the first byte in memory are used internal ly by the device to save the validation state. they are always set to the invalid state ( 0xa ) by the write command, and then may be set to the valid state ( 0x5 ) by the verify command. the lowest levels of the i/o protocols are described below. above the i/o protocol level, exactly the same bytes are transferred to and from the device to implement the commands and error codes documented below. 6 single - wire interface in this mode, communications to and from the ATECC608A take place over sda, a single asynchr onously timed wire, and the scl pin is not used as part of the communications channel. instead, the scl pin functions as a gpio pin. the sleep current specification values are guaranteed only if scl pin is held low or left unconnected. the overall commu nications structure is a hierarchical format: ? tokens i/o tokens implement a single data bit transmitted on the bus, or the wake - up event. ? flags flags consist of eight tokens (bits) that convey the direction and meaning of the next group of bits (if any) that may be transmitted. ? groups groups of data follow the command and transmit flags. they incorporate both a byte count and a checksum to ensure proper data transmission. ? packets packets of bytes form the core of the group (minus the byte count and crc) . they are either the input or output parameters of a cryptoauthentication command or status information from the ATECC608A. see the microchip website for the appropriate application notes for more details on how to use any microprocessor to easily generat e the signaling necessary to send these elements to the device, including c source code libraries. also see section 13.2 , wiring configuration for singl e - wire interface for more information about how to connect the device in the single - wire interface mode. 6.1 i/o tokens there are a number of i/o tokens, which may be transmitted over the single - wire interface: ATECC608A - preliminary ?2017 microchip technology page 39 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 ? input (to the ATECC608A): ? wake wake the devic e up from either the sleep or idle modes, or reset the i/o interface. ? zero send a single bit from the system to the device with a value of zero. ? one send a single bit from the system to the device with a value of one. ? output (from the ATECC608A): ? zeroout s end a single bit from the device to the system with a value of zero. ? oneout send a single bit from the device to the system with a value of one. the waveforms are the same in either direction, however, there are some differences in timing based upon the ex pectation that the host has a very accurate and consistent clock while the ATECC608A has significant part - to - part variability in its internal clock generator due to normal manufacturing and environmental fluctuations. the bit timings are designed to permit a standard uart running at 230.4kbaud to transmit and receive the tokens efficiently. each byte transmitted or received by the uart corresponds to a single bit received or transmitted by the device. the wake token is special since it requires an extra lo ng low pulse on the sda pin, which cannot be confused with the shorter low pulses that occur during a data token (i.e. zero, one, zeroout, or oneout). devices that are either in the idle or sleep mode will ignore all data tokens until they receive a legal wake token. if the processor is out of synchronization with the ATECC608A, it can send an additional wake token to the device, which will reset the i/o channel hardware on the device. note well: this may result in the loss of data stored in the command output buffer. 6.2 i/o flags the system is always the bus master, so before any i/o transaction, the system must send an eight bit flag to the device to indicate the i/o operation that will be subsequently performed. table 6 -1. io flags value name meaning 0x77 command after this flag, the system starts sending a command group to the device. the first bit of the group can follow immediately after the last bit of the flag. 0x88 transmit this command tells the device to wait for a bus turnaround time and then to start transmitting its response to the previously transmitted command group. 0xbb idle upon receipt of an idle flag, the device goes into the idle mode and remains there until the next wake token is received. 0xcc sleep upon receipt of a sleep flag, the device enters the low - power sleep mode until the next wake token is received. all other values are reserved and should not be used. ? transmit flag the transmit flag is used to turn around the bus so that the ATECC608A can send data back to the system. the bytes that the device returns to the system depend on the current state of the device and may include status, error code, or command results. ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 40 ? 2017 microchip technology when the device is busy executing a command, it ignores the sda pin and any flags that are sent by the system. see table 10 - 4 , command opcodes, short descriptions, and execution time for each command type?s execution delays. the system must observe these delays after sending a command to the device. ? idle flag the idle flag is used to transition the ATECC608A to the idle mode, which causes the input/output buffer to be flushed. it do es not invalidate the contents of the tempkey, messagedigest buffer and alt key registers. this flag can be sent to the device at any time that it will accept a flag. when the device is in the idle mode, the watchdog timer is disabled. ? sleep flag the sl eep flag transitions the ATECC608A to the low - power sleep mode, which causes a complete reset of the device, including invalidation of the contents of the sram and all volatile registers. this flag can be sent to the device at any time that it will accept a flag. 6.3 synchronization because the communications protocol is half - duplex, there is the possibility that the system and the ATECC608A will fall out of synchronization with each other. in order to speed recovery, the device implements a timeout that forces it to sleep under certain circumstances. 6.3.1 i/o timeout after a leading transition for any data token has been received, the ATECC608A will expect both the completion of the token and the start of the next (if this is not the last token of the group) to be p roperly received by the device within the t timeout interval. failure to send enough bits, or the transmission of an illegal token (e.g. a low pulse exceeding t zlo ), will cause the device to enter the sleep mode after the t timeout interval. the same timeout applies during the transmission of the command group. after the transmission of a legal command flag, the i/o timeout circuitry is enabled until the last expected data bit is received. the timeout counter is reset after every legal token; therefore, the total time to transmit the command may exceed the t timeout interval while the time between bits may not. the i/o timeout circuitry is disabled when the device is busy executing a command. 6.3.2 synchronization procedures if the device is not busy when the system sends a transmit flag, the device should respond within t turnaround . if t exec time has not already passed, the device may be busy, and the system should poll or wait until the maximum t exec time has elapsed. if the device still does not respond to a second transmit flag within t turnaround , it may be out of synchronization. at this point, the system may take the following steps to reestablish communication: 1. wait t timeout . 2. send the transmit flag. 3. if the device responds within t turnaround , then the sys tem may proceed with more commands. 4. send a wake token. 5. wait t whi . 6. send the transmit flag. 7. the device should respond with a 0x11 return status within t turnaround , after which the system may proceed with more commands. ATECC608A - preliminary ?2017 microchip technology page 41 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 7 i 2 c interface the i 2 c interface use s the sda and scl pins to indicate various i/o states to the ATECC608A. this interface is designed to be compatible at the protocol level with the microchip at24c16 serial eeprom operating at 1mhz. note well: there are many differences between the two devices (for example, the ATECC608A and at24c16 have different default i 2 c addresses); therefore, designers should read the respective datasheets carefully. the sda pin is normally pulled high with an external pull - up resistor because the ATECC608A includ es only an open- drain driver on its output pin. the bus master may either be open - drain or totem pole. in the latter case, it should be tri - stated when the ATECC608A is driving results on the bus. the scl pin is an input and must be driven both high and lo w at all times by an external device or resistor. 7.1 i/o conditions the device responds to the following i/o conditions: 7.1.1 device is asleep when the device is asleep, it ignores all but the wake condition. ? wake ? if sda is held low for a period of greater than t wlo , the device will exit low - power mode and after a delay of t whi , it will be ready to receive i 2 c commands. the device ignores any levels or transitions on the scl pin when the device is idle or asleep and during t wlo . at some point during t whi the scl pin is enabled and the conditions listed in section 7.1.2 , device is awake are honored. the wake condition requires that either the system processor manually drives the sda pin low for t wlo , or a data byte of 0x00 be transmitted at a clock rate sufficiently slow so that sda is low for a minimum period of t wlo . when the device is awake, the normal processor i 2 c hardware and/or software can be used for d evice communications up to and including the i/o sequence required, thus putting the device back into low - power (i.e. sleep) mode. when there are multiple ATECC608A devices on the bus, and the i 2 c interface is run at 133khz or slower, the transmission of c ertain data patterns (such as 0x00 ) will cause all the ATECC608A devices on the bus to wake- up. because subsequent device addresses transmitted along the bus will only match the desired devices, the unused devices will remain idle and not cause any bus con flicts. in the i 2 c mode, the device will ignore a wake sequence that is sent when the device is already awake. 7.1.2 device is awake when the device is awake, it honors the conditions listed below: ? data zero : if sda is low and stable while scl goes from low to h igh to low, then a zero bit is being transferred on the bus. sda can change while scl is low. ? data one: if sda is high and stable while scl goes from low to high to low, then a one bit is being transferred on the bus. sda can change while scl is low. ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 42 ? 2017 microchip technology figure 7 - 1. data bit transfer on i 2 c interface ? start condition : a high - to - low transition of sda with scl high is a start condition which must precede all commands. ? stop condition: a low - to - high transition of sda with scl high is a stop condition. after this condition is received by the device, the current i/o transaction ends. on input, if the device has sufficient bytes to execute a command, the device transitions to the busy state and begins execution. the stop condition should always be sent at the end of any packet se nt to the device. figure 7 - 2. start and stop conditions on i 2 c interface ? acknowledge (ack): on the ninth clock cycle after every address or data byte is transferred, the receiver will pull the sda pin low to acknowledge proper reception of the byte. ? not acknowledge (not ack): alternatively, on the ninth clock cycle after every address or data byte is transferred, the receiver can leave the sda pin high to indicate that there was a problem with the reception of the byte or that this byte completes the group transfer. figure 7 - 3. not ack and ack conditions on i 2 c interface scl d a t a li n e stable; data valid c hang e of data allowed sda scl sd a s t a r t condition s to p condition s p data output by receiver scl from master data output by t ransmitter c l o ck pu l s e f o r acknowledgment s t a r t condition s no t a ck no wl edg e a ck no wl edg e 1 2 8 9 ATECC608A - preliminary ?2017 microchip technology page 43 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 multiple ATECC608A devices can easily share the same i 2 c interface signals if the i2c_address byte in the configuration zone is programmed differently for each device on the bus. because all seven of the bits of the device address are programmable, ATECC608A can also share the i 2 c interface with any i 2 c device, including any serial eeprom. 7.2 i 2 c transmission to ATECC608A the transmission of data from the system to the ATECC608A is summarized in the table below. the order of transmission is as follows: ? start condition ? device address byte ? word address byte ? optional data bytes (1 through n) ? stop condition figure 7 - 4. normal i 2 c transmission to ATECC608A sda is driven low by ATECC608A ack periods. the tables below label th e bytes of the i/o transaction. the column labeled ?i 2 c name? provides the name of the byte as described in the at24c16 datasheet. table 7 -1. i 2 c transmission to ATECC608A name i 2 c name description device address device address this byte selects a particular device on the i 2 c interface. ATECC608A is selected if bits 1 thru 7 of this byte match bits 1 thru 7 of the i2c_address byte in the configuration zone. bit 0 of this byte is the standard i 2 c r/w bit, and should be zero to indicate a write operation (the bytes fol lowing the device address travel from the master to the slave). word address word address this byte should have a value of 0x03 for normal operation. see sections 7.2.1 , word address values and 7.6 , address counter for more information. command data1,n the command group, consisting of the count, command packet, and the two byte crc. the crc is calculated over the size and packet bytes. see section 10.1 , i/o groups . because the device treats the command input buffer as a fifo, the input group can be sent to the device in one or many i 2 c command groups. the first byte sent to the device is the count, so after the device receives that number of bytes, it will ignore any subsequently received bytes until execution is finished. 1 - 7 8 9 1 - 7 8 9 1 - 7 8 9 1 - 7 8 9 1 - 7 8 9 s c l s da s p r / w a c k 1 a c k 1 a c k 1 word a ddr ess data 1 a c k 1 data 2 start condition stop condition device address a c k 1 data n ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 44 ? 2017 microchip technology the system must send a stop condition after the last command byte to ensure that ATECC608A will start the computation of the command. failure to send a stop condition may eventual ly result in a loss of synchronization; see section 7.8 , i2c synchronization for recovery procedures. 7.2.1 word address values during an i 2 c write packet, the ATECC608A interprets th e second byte sent as the word address, which indicates the packet function as it is described in the table below: table 7 -2. word address values name value description reset 0x00 reset the address counter. the next i 2 c read or write transaction will start with the beginning of the i/o buffer. sleep (low - power) 0x01 the ATECC608A goes into the low power sleep mode and ignores all subsequent i/o transitions until the next wake flag. the entire volatile state of the device is reset. idle 0x02 the ATECC608A goes into the idle mode and ignores all subsequent i/o transitions until the next wake flag. the contents of tempkey, messagedigestbuffer, and alternate key registers are retained. command 0x03 write subsequent bytes to sequential addresses in the input command bu ffer that follow previous writes. this is the normal operation. reserved 0x04 C 0xff these addresses should not be sent to the device. 7.2.2 command completion polling after a complete command has been sent to the ATECC608A, the device will be busy until the command computation completes. the system has two options for this delay as noted below: ? polling: the system should wait t exec (typical) and then send a read sequence (see section 7.5 , i 2 c transmission from the ATECC608A ). if the device not acks the device address, then it is still busy. the system may delay for some time or immediately send another read sequence, again looping on not ack. after a total delay of t exec (max), the device will have completed the computation and return the results. ? single delay: the system should wait t exec (max) after which the device will have completed execution, and the result can be read from the device using a normal read sequence. 7.3 s leep sequence upon completion of the use of the ATECC608A by the system, the system should issue a sleep sequence to put the device into low - power mode. this sequence consists of the proper device address followed by the value of 0x01 as the word address f ollowed by a stop condition. this transition to the low - power state causes a complete reset of the device?s internal command engine and input/output buffer. it can be sent to the device at any time when it is awake and not busy. 7.4 idle sequence if the total sequence of required commands exceeds t watchdog , then the device will automatically go to sleep and lose any information stored in the volatile registers. this action can be prevented by putting the device into the idle mode prior to completion of the watc hdog interval. when the device receives the wake token, it will then restart the watchdog timer and execution can be continued. ATECC608A - preliminary ?2017 microchip technology page 45 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 the idle sequence consists of the proper device address followed by the value of 0x02 as the word address followed by a stop con dition. it can be sent to the device at any time when it is awake and not busy. 7.5 i 2 c transmission from the ATECC608A when the ATECC608A is awake and not busy, the bus master can retrieve the current buffer contents from the device using an i 2 c read. if vali d command results are available, the size of the group returned is determined by the particular command which has been run. otherwise, the size of the group (and the first byte returned) will always be four: count, status/error, and 2 - byte crc. the bus tim ing is shown in figure 9 - 4 , i2c synchronous data timing . table 7 -3. i 2 c transmission from the ATECC608A name i 2 c name direction description device address device address to slave this byte selects a particular device on the i 2 c interface and ATECC608A will be selected if bits 1 thru 7 of this byte match bits 1 thru 7 of the i2c_address byte in the configuration zone. bit 0 of this byte is the standard i 2 c r/w pin, and should be one to i ndicate that the bytes following the device address travel from the slave to the master (read). data data1,n to master the output group, consisting of the count, status/error byte or the output packet followed by the two byte crc per section 10.1 , i/o groups . the status, error, or command outputs can be read repeatedly by the master. each time a read command is sent to the ATECC608A along the i 2 c interface, the device transmits the next sequential byte in the output buffer. see the following section for details on how the device handles the address counter. if the ATECC608A is busy, idle, or asleep, it will not ack the device address on a read sequence. if a partial command has been sent to the device and a read sequence [start + deviceaddress(r/w == r)] is sent to the device, then the ATECC608A will not ack the device address to indicate that no data is available to be read. 7.6 address counter writes to and/or reads from the ATECC608A i/o buffer over the i 2 c interface are treated as if the device were a fifo. either the i 2 c byte or page write/read protocols can be used. the number of bytes transferred with each page sequence does not affect the operation of the device. the first byte transmitted to the device is treated as the size byte. any attempt to send more than this number of bytes, or any attempts to write beyond the end of the i/o buffer (71 bytes) will cause the ATECC608A to not ack those bytes. after the host writes a single command byte to the input buffer, reads are prohibited until after the device completes command execution. attempts to read from t he device prior to the last command byte being sent will result in an ack of the device address but all ones ( 0xff ) on the bus during the data intervals because the device is still waiting for the completion of the command transmission. if the host attempt s to send a read byte after the last byte of the command has been transmitted, the device will be executing the command and will not ack the device address. data may be read from the device under the following three conditions: ? on power - up, the single byte 0x11 (section 10.3 , status/error codes ) can be read inside a four byte group. ? if a complete block has been received by the device, but there are an y errors in parsing or executing the command, a single byte of error code is available (also inside a four byte group). ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 46 ? 2017 microchip technology ? upon completion of a command execution from 1 to 32 bytes of command, results are available to be read inside a group of 4 to 35 bytes. any attempt to read beyond the end of the valid output buffer returns 0xff to the system, and the address counter does not wrap around to the beginning of the buffer. there may be situations where the system may wish to re - read the output buffer, for exam ple when the crc check reveals an error. in this case, the host should send a two - byte sequence to the ATECC608A consisting of the correct device address and a word address of 0x00 (reset, per table 7 - 2 , word address values ), followed by a stop condition. this causes the address counter to be reset to zero and permits the data to be rewritten (or re - read) to (or from) the device. this address reset seq uence does not prohibit subsequent read operations if data were available for reading in the i/o buffer prior to the sequence execution. after one or more read operations to retrieve the results of a command execution, the first write operation resets the address counter to the beginning of the i/o buffer. 7.7 smbus timeout the ATECC608A supports the smbus timeout feature in which the ATECC608A will reset its serial interface and release the smbus (i.e. stop driving the bus and let sda float high) if the scl pi n is held low for more than the minimum t timeout specification. the ATECC608A will be ready to accept a new start condition before t timeout maximum has elapsed. figure 7 - 5. smbus timeout 7.8 i 2 c synchronization it is possible for the system to lose synchronization with the i/o port on the ATECC608A, perhaps due a system reset, i/o noise, or other condition. under this circumstance, the ATECC608A may not respond as expected, may be asleep, or may be transmitting data during an interval when the system is expecting to send data. to resynchronize, the following procedure should be followed: 1. to ensure an i/o channel reset, the system should send the standard i 2 c software reset sequence, as follows: ? a start bit condition. ? nine cycles of scl, with sda held high. ? another start b it condition. ? a stop bit condition. it should then be possible to send a read sequence, and if synchronization has completed properly, the ATECC608A will ack the device address. the device may return data or may leave the bus floating (which the system wil l interpret as a data value of 0xff ) during the data periods. if the device does ack the device address, the system should reset the internal address counter to force the ATECC608A to ignore any partial input command that may have been sent. this can be accomplished by sending a write sequence to word address 0x00 (r eset), followed by a stop condition. s c l t timeou t (max) t timeou t (min) device will release bus and be ready to accept a new start condition within this time. ATECC608A - preliminary ?2017 microchip technology page 47 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 2. if the device does not respond to the device address with an ack, then it may be asleep. in this case, the system should send a complete wake token and wait t whi after the rising edge. the system may then send another r ead sequence, and if synchronization has completed, the device will ack the device address. 3. if the device still does not respond to the device address with an ack, then it may be busy executing a command. the system should wait the longest t exec (max) and then send the read sequence, which will be acknowledged by the device. ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 48 ? 2017 microchip technology 8 general purpose i/o pin when the single - wire interfaces is enabled, the scl pin is available to be used as a gpio pin. it may be used to drive one or two leds or can be connected to a n external tamper detection switch or connected in many other ways. when configured as an output, it may be used as an enable pin for some external component in the system which may require cryptographic validation prior to assertion. on initial power - up, the pin is always temporarily configured as an input. during the device initialization, which occurs with the very first wake operation, the contents of the i2c_address field are read, and the gpio pin will be driven to the state. the direction (input or o utput) and state (if an output) of the gpio pin will remain unchanged during sleep and idle states. the actions of this pin are controlled by the i2c_address byte in the configuration zone, and the gpio mode of the info command as described in the table be low: table 8 -1. gpio mode bit 3 bit 2 bit 1 bit 0 name power - up state meaning x x 0 0 disable input the scl pin is unused and should be tied to gnd. any attempt to execute the gpio mode of the info command will result in an error code being returned to the system firmware. the gpio mode of the info command will also return an error code if the part is configured for i 2 c operation. 0 0 0 1 auth0 low the scl pin will be permanently configured as an output and will be driven to a zero (default) state when the first wake operation after power - up occurs. the pin can then be driven to the opposite ( ' 1 ') state by the info command if a prior authorization has been performed using the signalkey slot. the g pio output mode of the info command can be used to reset the pin back to the default value without authorization. the gpio retains its state so long as v cc remains above 2v. 0 1 0 1 auth1 high as auth0; however, the default state after power - up is one. 1 x 0 1 intrusion detection input the scl pin will be permanently configured as an input. the persistent latch is set via authorization and is cleared if scl falls below 1.8v. any falling edge on the scl pin resets the persistent latch to zero regardless of whether or not the ATECC608A is in wake or sleep mode. a gpio read via the info (mode=3) command returns the value of the persistent latch; not the current state of the pin. x x 1 0 input input the scl pin will remain permanently configured as an input. execution of the info command will permit the current state on the pin to be returned to the system firmware. x 0 1 1 output0 low the scl pin will be configured as an output and will be driven to a zero state when the first wake operation occurs. subsequent info commands can be executed to drive the pin high or low. alternatively, the info command can be used to change the gpi pin to an input. x 1 1 1 utput1 high as utput0 however, the default state after power - up is one. the gpio pin has active drivers for both the high and low output states to enable connection to two different leds, which may be connected to v cc and gnd respectively. if an led is connected to a supply voltage higher than v cc , it may not turn off completely when the gpio pin is high. in this case, the gpio pin should be transitioned to an input to completely turn off the led. ATECC608A - preliminary ?2017 microchip technology page 49 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 9 electrical characteristics 9.1 absolute maximum ratings* operating temperature .......................... -40 c to 85 c storage temperature ........................... -65 c to 150c maximum operating voltage ................................ 6 .0 v dc output current ................................................ 5ma voltage on any pin ...................... - 0.5v to (v cc + 0.5v) *notice: stresses beyond those l isted under ?absolute maximum ratings? may cause permanent damage to the device. this is a stress rating only and functional operation of the device at these or any other conditions beyond those indicated in the operational sections of this specification a re not implied. exposure to absolute maximum rating conditions for extended periods may affect device reliability. 9.2 reliability the ATECC608A is fabricated with the microchip high reliability of the cmos eeprom manufacturing technology. table 9 -1. eeprom reliabili ty parameter min typical max units write endurance at 85 c (each byte) 400,000 write cycles data retention at 55 c 10 years data retention at 35 c 30 50 years read endurance unlimited read cycles ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 50 ? 2017 microchip technology 9.3 ac parameters: all i/o interfaces figure 9 - 1. ac timing diagram: all interfaces figure 9 - 2. ac parameters: all i/o interfaces parameter symbol direction min typ max unit notes power - up delay (2) t pu to crypto authentication 100 s minimum time between v cc > v cc min prior to measurement of t wlo . wake low duration t wlo to crypto authentication 60 s wake high delay to data comm. t whi to crypto authentication 1500 s sda should be stable high for this entire duration. high side glitch filter at active t hignore_a to crypto authentication 45 (1) ns pulses shorter than this in width will be ignored by the device, regardless of its state when active. low side glitch filter at active t lignore_a to crypto authentication 45 (1) ns pulses shorter than this in width will be ignored by the device, regardless of its state when active. low side glitch filter at sleep t lignore_s to crypto authentication 15 (1) s pulses shorter than this in width will be ignored by the device when in sleep mode. watchdog timeout t watchdog to crypto authentication 0.7 1.3 1.7 s time from wake until device is forced into sleep mode if config.chipmode.bit2 is 0. see section 10.6 , watchdog failsafe . 7.6 10 13.1 s watchdog time : config.chipmode.bit2 is 0. note 1. these parameters are guaranteed through characterization , but not tested. 2. the power - up delay will be significantly longer if power - on self test is enabled in the configuration zone. data comm wake t lignore t hignore noise suppresion t wlo t whi ATECC608A - preliminary ?2017 microchip technology page 51 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 9.3.1 ac parameters: single - wire interface figure 9 - 3. ac timing diagram: single - wire interface table 9 -2. ac parameters: single - wire interface applicable from t a = -40 c to +85 c, v cc = +2.0v to +5.5v, cl =100pf (unless otherwise noted). parameter symbol direction min typ max unit notes start pulse duration t start to crypto authentication 4.10 4.34 4.56 s from crypto authentication 4.60 6 8.60 s zero transmission high pulse t zhi to crypto authentication 4.10 4.34 4.56 s from crypto authentication 4.60 6 8.60 s zero transmission low pulse t zlo to crypto authentication 4.10 4.34 4.56 s from crypto authentication 4.60 6 8.60 s bit time (1) t bit to crypto authentication 37 39 s if the bit time exceeds t timeout then ATECC608A may enter the sleep mode. see section 6.3.1 , i/o timeout . from crypto authentication 41 54 78 s turn around delay t turnaround from crypto authentication 64 96 131 s ATECC608A will initiate the first low going transition after this time interval following the initial falling edge of the start pulse of the last bit of the transmit flag. to crypto authentication 93 s after ATECC608A transmits the last bit of a group, system must wait this interval before sending the first bit of a flag. it is measured from the falling edge of the start pulse of the last bit transmitted by ATECC608A. io timeout t timeout to crypto authentication 45 65 85 ms ATECC608A may transition to the sleep mode if the bus is inactive longer than this duration. see section 6.3.1 . note 1. start, zlo, zhi, and bit are designed to be compatible with a standard uart running at 2 30.4kbaud for both transmit and receive. the uart should be set to seven data bits, no parity and one stop bit. t start t zhi t zlo logic ? t start t bit logic 1 t start t turnaround t start sda ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 52 ? 2017 microchip technology 9.3.2 ac parameters: i 2 c interface figure 9 - 4. i 2 c synchronous data timing table 9 -3. ac characteristics of i 2 c interface applicable over recommended operating range from ta = - 40c to + 85c, v cc = +2.0v to +5.5v, cl = 1 ttl gate and 100pf (unless otherwise noted). symbol parameter min max units f sck sck clock frequency 0 1 mhz t high sck high time 400 ns t low sck low time 400 ns t su.sta start setup time 250 ns t hd.sta start hold time 250 ns t su.sto stop setup time 250 ns t su.dat data in setup time 100 ns t hd.dat data in hold time 0 ns t r input rise time (1) 300 ns t f input fall time (1) 100 ns t aa clock low to data out valid 50 550 ns t dh data out hold time 50 ns t timeout smbus timeout delay 25 75 ms t buf time bus must be free before a new transmission can start. (1) 500 ns note 1. values are based on characterization and are not tested. 2. ac measurement conditions: ? rl (con nects between sda and v cc ): 1.2k (for v cc +2.0v to +5.0v) ? input pulse voltages: 0.3v cc to 0.7v cc ? input rise and fall times: 50ns ? input and outp ut timing reference voltage : 0.5v cc sc l sd a in sd a ou t t f t high t low t low t r t a a t dh t buf t su.s t o t su.d a t t hd.d a t t hd.s t a t su.s t a ATECC608A - preliminary ?2017 microchip technology page 53 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 9.4 dc parameters: all i/o interfaces table 9 -4. dc parameters on all i/o interfaces parameter symbol min typ max unit notes ambient operating temperature t a - 40 85 c power supply voltage v cc 2.0 5.5 v active power supply current i cc 2 3 ma waiting for i/o during i/o transfers or execution of non - ecc commands. independent of clock divider value. ? 14 ma during ecc command execution. clock divider = 0x0 6 ma during ecc command execution. clock divider = 0x5 3 ma during ecc command execution. clock divider = 0xd idle power supply current i idle 800 a when device is in idle mode, v sda and v scl < 0.4v or > v cc C 0.4 sleep current i sleep 30 150 na when device is in sleep mode, v cc 3.6v, v sda and v scl < 0.4v or > v cc C 0.4, t a 55c 2 a when device is in sleep mode. output low voltage v ol 0.4 v when device is in active mode, v cc = 2.5 C 5.5v output low current i ol 4 ma when device is in active mode, v cc = 2.5 C 5.5v, v ol = 0.4v theta ja ? ja 166 c/w soic (ssh) 173 c/w udfn (mah) 146 c/w rbh ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 54 ? 2017 microchip technology 9.4.1 v ih and v il specifications the input levels of the device will vary dependent on the mode and voltage of the device. the input voltage thresholds when in sleep or idle mode are dependent on the v cc level as shown in figure 8 - 5. when in sleep or idle mode the ttlenable bit has no effect. when the device is active (i.e. not in sleep or idle mode), the input voltage thresholds are different depending upon the state of ttlenable (bit 1) within the chipmode byte in the configuration zone of the eeprom. if the voltage supplied to the v cc pin of the ATECC608A is different than the system voltage to which the input pull - up resistor is connected, then the system designer may choose to set ttlenable to zero, which enables a fixed input threshold also shown in figure 8.5 table 8 - 5 also shows the guaranteed levels of operation when operating in this mode.table 8 - 5 only applies when the device is active: table 9 -5. v il , v ih on all i/o interfaces (ttlenable=0) parameter symbol min typ max unit notes input low voltage v il - 0.5 0.5 v when device is active and ttlenable bit in configuration memory is zero; otherwise see above. input high voltage v ih 1.5 v cc + 0.5 v when device is active and ttlenable bit in configuration memory is zero; otherwise see above. figure 9 - 5. v ih and v il in sleep and idle mode or when ttlenable = 0 on all i/o interfaces ATECC608A - preliminary ?2017 microchip technology page 55 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 when a common voltage is used for the ATECC608A v cc pin and the input pull - up resistor, then the ttlenable bit should be set to a one, which permits the input thresholds to track the supply as shown below . figure 9 - 6. v ih and v il when active and ttlenable = 1 on all i/o interfaces ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 56 ? 2017 microchip technology 10 general command information 10.1 i/o groups regardless of the i/o protocol being used (i.e. either single - wire interface or i 2 c); security commands are sent to the device and responses received from the device within a group that is constructed in the following way: table 10 -1. i/o groups byte name mea ning 0 count number of bytes to be transferred to (or from) the device in the group, including count byte, packet bytes, and checksum bytes. the count byte should therefore always have a value of (n+1), where n is equal to the number of bytes in the packet plus the two checksum bytes. for a group with one count byte, 50 packet bytes, and two checksum bytes, the count byte should be set to 53. the maximum size group (and value of count) is 155 bytes, and the minimum size group is four bytes. values out side this range will cause the device to return an i/o error. 1 to (n - 2) packet command, parameters and data, or response. see below for more details. n - 1, n checksum crc - 16 verification of the count and packet bytes. the crc polynomial is 0x8005 . the initial register value should be zero and after the last bit of the count and packet have been transmitted; the internal crc register should have a value that matches the checksum bytes in the block. the first crc byte transmitted (n - 1) is the least - signif icant byte of the crc value, so the last byte of the group is the most - significant byte of the crc. the ATECC608A is designed in such a way that the count value in the input group should be consistent with the size requirements that are specified in the command parameters. if the count value is inconsistent with the command opcode and/or parameters within the packet, then the ATECC608A will respond in different ways depending upon the specific command. the response may either include an error indication or some input bytes may be silently ignored. 10.2 command packets the command packet is broken down as shown in table 10 - 2 , below: table 10 -2. command packets byte name meaning 0 opcode the command code. see section 10.4 , command summary and execution times . 1 param1 the first parameter; always present. 2 C 3 param2 the second parameter; always present. 4+ data optional remaining input data. after the ATECC608A receives all the bytes in a group, the device transitions to the busy state and attempts to execute the command. neither status nor results can be read from the device when it is busy. during this time, the i/o interface of the device ignores all sda transitions regardless of the i/o interface selected. the command execution delays are listed in section 10.4 . if insufficient bytes are sent to th e device when it is in single - wire mode, the device automatically transitions to the low - power sleep mode after the t timeout interval. in i 2 c mode, the device continues to wait for the remaining bytes until the watchdog timer limit t watchdog is reached, or a start/stop condition is received by the device. ATECC608A - preliminary ?2017 microchip technology page 57 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 10.3 status/error codes the device does not have a dedicated status register, so the output fifo is shared among status, error, and command results. all outputs from the device are returned to the system as com plete groups which are formatted identically to input groups: ? count ? packet ? two byte crc after the device receives the first byte of an input command group, the system cannot read anything from the device until the system has sent all the bytes to the device. after wake and after execution of a command, there will be error, status, or result bytes in the device's output register that can be retrieved by the system. when the length of that group is four bytes, the codes returned are detailed in table 10 - 3 , below. some commands return more than four bytes when they execute successfully. the resulting packet description is listed in the command section that follows. crc errors are always returned before any other type of error. they indicate that some sort of i/o error occurred, and that the command may be resent to the device. no particular precedence is enforced among the remaining errors if more than one occurs. table 10 -3. status/error codes in four byte groups state description error/status description successful command execution 0x00 command executed successfully. checkmac or verify miscompare 0x01 the checkmac or verify command was properly sent to the device, but the input client response did not match the expected value. parse error 0x03 command was properly received but the length, command opcode, or parameters are illegal regardless of the state (volatile and/or eeprom configuration) of the ATECC608A. changes in the value of the command bits must be made before it is re - attempted. ecc fault 0x05 a computation error occurred during ecc processing that caused the result to be invalid. retrying the command may resul t in a successful execution. self test error 0x07 there was a self test error and the chip is in failure mode waiting for the failure to be cleared. execution error 0x0f command was properly received but could not be executed by the device in its current state. changes in the device state or the value of the command bits must be made before it is re - attempted. after wake, prior to first command 0x11 indication that ATECC608A has received a proper wake token. watchdog about to expire 0xee there is insuf ficient time to execute the given command before the watchdog timer will expire. the system must reset the watchdog timer by entering the idle or sleep modes. crc or other communications error 0xff command was not properly received by at88sha204 and should be re - transmitted by the i/o driver in the system. no attempt was made to parse or execute the command. ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 58 ? 2017 microchip technology 10.4 command summary and execution times 10.4.1 command summary the following commands are implemented by the atecc6 08a: table 10 -4. command opcodes, short descriptions, and execution time command opcode description aes 0x51 execute the aes - ecb encrypt or decrypt functions. calculate a galois field multiply. checkmac 0x28 verify a mac calculated on another cryptoauthentication device. counter 0x24 read or increment one of the monotonic counters derivekey 0x1c derive a target key value from the target or parent key. ecdh 0x43 generate an ecdh master secret using stored private key and input public key. gendig 0x15 generate a data digest from a random or input seed and a key. genkey 0x40 generate an ecc public key. optionally generate an ecc private key. info 0x30 return device state information. kdf 0x56 implement the prf or hkdf key derivation functions lock 0x17 prevent further modifications to a zone or slot of the device. mac 0x08 calculate response from key and other internal data using sha - 256. nonce 0x16 generate a 32 - byte random number and an internally stored nonce. privwrite 0x46 write an ecc private key into a slot in the data zone. random 0x1b generate a random number. read 0x02 read four bytes from the device, with or without authentication and encryption. secureboot 0x80 validate code signature or code digest on power - up selftest 0x77 test the various internal cryptographic computation elements sign 0x41 ecdsa signature calculation. sha 0x47 computes a sha - 256 or hmac digest for general purpose use by the system. updateextra 0x20 update bytes 84 or 85 within the configuration zone after the configuration zone is locked. verify 0x45 ecdsa verify calculation. write 0x12 write 4 or 32 bytes to the device, with or without authentication and encryption. ATECC608A - preliminary ?2017 microchip technology page 59 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 10.4.2 command execution times during execution of a properly received command, the device will be busy and not respond to transitions on the pins. the interval during which the device will be busy varies depending upon the command parameters , device state , the environmental conditions, and other factors. the following table shows representative times for the duration to execute the command assuming no error conditions, typical mode setting and chip state . some modes may be faster, while others may be slower. table 10 -5. typical execution time in m s command condition clock divider 0 clock divider 5 clock divider d aes mode = encrypt 1 1 1 checkmac 8 8 8 counter mode = read 0.5 0.5 0.5 derivekey 15 15 15 ecdh target = eeprom 28 94 370 gendig 11 11 11 genkey (first) 1 mode = create 59 115 350 genkey (subsequent) 1 mode = create 59 115 350 info devrev 0.5 0.5 0.5 kdf mode = prf 99 99 99 lock mode = config, check crc 15 15 15 mac 7 7 7 nonce (first) 1 mode = random 17 17 17 nonce (subsequent) 1 mode = random 11 11 11 privwrite 29 29 29 random (first) 1 15 15 15 random (subsequent) 1 15 15 15 read 32 bytes 0.8 0.8 0.8 secure boot stored digest. no encrypt or mac 0.9 0.9 0.9 selftest mode = 0xff (all algorithms) 110 350 1400 sign (first) 1 mode = external 64 124 366 sign (subsequent) 1 mode = external 60 113 378 sha update, message = 64 bytes 1 1 1 updateextra 8 8 8 verify mode = fixed 27 90 354 write 32 bytes 8 8 8 ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 60 ? 2017 microchip technology in a typical polling configuration , the host software should delay for the interval in the table above and then start polling to determine actual command completion. the three columns in this table correspond to the legal values of the clock divider field of the chip mode configuration byte. in most but not all cases, failing commands wil l return relatively quickly. some commands noted with ( 1 ) in the table above use the random number generator (rng). the first time the rng is called in any wake/power cycle there will be additional time for the nist instantiation sequence. subsequent use o f the rng for any purpose does not require this to be re - run. (first) indicates that this delay is appropriate for the first execution of this command after power - up or wake but before any random numbers have been generated. (subsequent) indicates that thi s delay is appropriate for situation in which a random number has already been generated. do not use the numbers in this table for software timeouts that drive errors. these delays represent typical times only and the actual execution time may be shorter or significantly longer depending on the mode, chip state and/or configuration. timeout intervals should be at least 50ms more than the typical values listed in the table above when configured with the clock divider of 00. other clock divider values will r equire additional extra time. the following situations can cause commands to take longer to execute than the typical times above: ? some modes indicate extra computation, for instance an output validation mac, that takes extra time vs the non- mac version of the command ? in some cases the current state of the chip may require additional operations to be performed which can increase the execution time ? the first random number generated after a wake/power - on will take extra time for the drbg instantiation operati on , as indicated in the table above ? some commands may write to the eeprom instead of an internal sram register. depending on the number of pages and/or internal elements to be written, this will take extra time ? the limited use function for each slot requir es that the internal monotonic counter be incremented prior to the use of the key. depending on the current count, the additional execution time can vary significantly. the counter command may also increment one of the monotonic counters ? the various intern al security sequences include random delays. on a statistically infrequent basis, the cumulative computation delay may be much longer than typical commands may take substantially more time to execute under these and other conditions . the following table sh ows sample execution times for a few commands where the modes, chip state and parametric conditions have been configured to be close to the longest delay possible. this data was gathered with a clock divider value of 00. table 10 -6. example long execution time in ms command example long execution time (ms) sign 75 genkey 90 verify 67 nonce 20 secureboot (full store) 82 ATECC608A - preliminary ?2017 microchip technology page 61 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 10.5 address encoding the read and write commands include a single 16 bit address in param2, which indicates the memory location to be accessed. in all cases, the least significant two bytes of the byte address should be dropped from the parameter that is passed to the device to create a word ad dress. the read and write commands support either 4 or 32 byte accesses. when 32 bytes are being accessed, the offset (i.e. the least significant three bits of the word address) must be present in the parameter, but their value in the parameter is ignored, and the operation proceeds assuming they are zero (i.e. all 32 byte accesses are block aligned). 10.5.1 zone encoding the value in param1 controls which zone the command accesses. see section 2.4.1 , configuration zone locking to obtain more information on what controls the locked and unlocked states for each zone. all other zone values are reserved and should not be used. table 10 -7. zone encoding (param1) zone param1 v alue size read write config 0 1024 bits 128 bytes 4 blocks always available. partially, when unlocked. never when locked. never encrypted. otp 1 512 bits 64 bytes 2 blocks never when unlocked. always when locked. all writeable when unlocked using write . when locked, no writes are permitted. data 2 9664 bits 1208 bytes 16 slots never when unlocked; otherwise, controlled by issecret and encryptread. all writeable when unlocked. when locked, writes controlled by writeconfig. table 10 -8. address encoding for config and otp zones (param2) zone byte 1 byte 0 unused unused block offset config bits 0 ? 7 bits 5 ? 7 bits 3 ? 4 bits 0 ? 2 otp bits 0 ? 7 bits 4 7 bit 3 bits 0 2 table 10 -9. address encoding for data zone (param2) zone byte 1 byte 0 unused block unused slot offset data slots 0 C 7 bits 1 ? 7 bit 0 bit 7 bits 3 ? 6 bits 0 ? 2 data slot 8 bits 4 ? 7 bits 0 3 bit 7 bits 3 6 bits 0 2 data slots 9 C 15 bits 2 ? 7 bits 0 and 1 bit 7 bits 3 ? 6 bits 0 ? 2 ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 62 ? 2017 microchip technology within each zone, there are various access restrictions as noted in the table below: table 10 - 10. legal block/slot values zone name legal block legal slot notes config 0 C 3 addresses below 16 (block 0, offset 16) can never be written. addresses from 84- 87 cannot be written using the write command. both 4 - byte and 32 - byte reads/writes are permitted. otp 0 C 1 when otp is unlocked, all offsets in both blocks are available to use with 4 or 32 byte reads. if otp zone is locked, no writes to otp are permitted. data 0 C 1 0 C 7 all offsets in all slots available for both read and write . a 4 - byte access is permitted on a particular slot only if slotconfig.issecret is zero. 0 C 12 8 0 C 2 9 C 15 in the following table, address is the value to be passed to the read and/or write commands as the address parameter to access data in the specific blocks using a 32 byte read or write. size is the number of implemented eprom bytes within that particular block. to use a four byte read or write command to access the first word in a block, use the addresses shown in table 10- 11 ; otherwise, the least significant three bits of the address field should include the word address to be accessed. the 32 byte access is permitted in blocks that contain less than 32 implemented memory bytes. the extra bytes will be returned as zero on a read and ignored on a write. ATECC608A - preliminary ?2017 microchip technology page 63 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 table 10 - 11. data zone address values block 0 block 1 blo ck 2 block 3 slot address size address size address size address size 0 0x0000 32 0x0100 4 1 0x0008 32 0x0108 4 2 0x0010 32 0x0110 4 3 0x0018 32 0x0118 4 4 0x0020 32 0x0120 4 5 0x0028 32 0x0128 4 6 0x0030 32 0x0130 4 7 0x0038 32 0x0138 4 8 0x0040 32 0x0140 32 0x0240 32 0x0340 32 9 0x0048 32 0x0148 32 0x0248 8 10 0x0050 32 0x0150 32 0x0250 8 11 0x0058 32 0x0158 32 0x0258 8 12 0x0060 32 0x0160 32 0x0260 8 13 0x0068 32 0x0168 32 0x0268 8 14 0x0070 32 0x0170 32 0x0270 8 15 0x0078 32 0x0178 32 0x0278 8 example: to complete a four byte read of the 53rd through 56th byte of slot 9, the word address would be: the 53 rd byte is the 21 st byte in block 1 (53 divided by 32 is 1, 53 minus 32 is 21). the 21 st byte is located at byte offset 0x14 , which is at word offset 0x05 ( 0x14 divided by 4 is 0x05 ). per table 10 - 9 , the address parameter to the read command is 000000 01 0 1001 101 or 0x014 . 000000 01 0 1001 101 0 1 4 d w ord o f fset slot number unused block number unused ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 64 ? 2017 microchip technology 10.6 watchdog failsafe after the ATECC608A receives a wake token, a watchdog counter starts within the device after t watchdog , the device enters sleep mode regardless of whether some i/o transmission or command execution is in progress. there is no way to reset the coun ter other than to put the device into sleep or idle mode and then wake it up again. the watchdog timer is implemented as a fail - safe mechanism where no matter what happens on either the system side or inside the device, including any i/o synchronization is sue, power consumption will fall to the ultra - low sleep level automatically. the device resets the values stored in the sram and internal status registers when it transitions to the sleep mode; however, if the device is explicitly put into the idle mode th rough the appropriate i/o sequence, then the device retains the contents of the sram registers. normally, all command sequences must complete within t watchdog if they require a state that is stored in the sram registers. if there is a need to implement a command sequence that is longer than the watchdog interval, the system software can use this idle mode mechanism to ensure that the sequence can complete successfully.. if a command is attempted when insufficient time remains prior to watchdog timer execut ion, the device will return the watchdog timeout error code without attempting to execute the command. this feature prevents situations in which the command may only be partially executed at the time the watchdog timer resets the device. in particular, the limited use counter is always decremented prior to execution of the crypto computation; therefore, an aborted command might result in fewer counts remaining without the result being available to the system. the device will never be left in an unusable sta te after an aborted command. due to the extended nature of some networking sequences, the ATECC608A provides an extended watchdog interval to be enabled via the configuration zone chipmode byte. for highest security, microchip always recommends the shorter watchdog interval. see section 2.2 for more details. ATECC608A - preliminary ?2017 microchip technology page 65 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 11 detailed command descriptions 11.1 aes command the aes command executes the aes al gorithm in one of two modes: encrypt - ecb: 16 bytes of cleartext are expected on input, the aes encrypt operation is performed on the input block and the output 16 bytes are the encrypted result. decrypt - ecb: 16 bytes of ciphertext are expected on input, the aes decrypted operation is performed on the input block and the output 16 bytes are the cleartext result. galois field multiply (gfm): take the first 16 bytes input after param2 as h and the second 16 bytes as the input data and calculate gfm to be use d in the aes - gcm aead functionality. this mode does not involve secrets or anything stored on the chip. if this mode is selected the remaining mode bits are ignored. the aes key can be located in any of 4 possible locations if the input has 64 valid bytes or either of the 2 possible locations if the input has 32 valid bytes. this selection is controlled by bits 6:7 of the mode byte. the aes command mode is enabled via bit 0 of byte 13 in the configuration area. if 1, the command is enabled, if 0 it is disab led. this configuration byte cannot be written in the field. table 11 -1. input parameters name size notes opcode aes 1 0x51 param1 mode 1 bit 0 - 2: if 000, aes - ecb encrypt if 001, aes - ecb decrypt if 011, calculate galois field multiply (gfm) on the input data all other values reserved, do not use bits 3 - 5: reserved for future use, must be zero. bits 6 - 7: use this 16 byte aes block within the source field as the aes key. an error is returned if the source field does not have 64 valid bytes and one of the upper keys is selected. param2 keyid 2 the key slot in the eeprom to be used as the secret key in the aes calculation if mode:0 is 0. if 0xffff, then tempkey is the source of the aes key. data input 16 the input to the aes or gcm operation. table 11 -2. output parameter name size notes response 1 or 16 if the aes operation was successful the output is 16 bytes, either the aes ecb or gcm output. otherwise if any error has occurred, the error code. ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 66 ? 2017 microchip technology 11.2 checkmac command the checkmac command calculates a mac response that would have been generated on a different ate cc608a, atecc508a, or atsha204a device and then compares the result with the input value. it returns a boolean result to indicate the success or failure of the comparison. prior to running this command, the nonce and/or gendig commands may have been optionally run to create a key or nonce value in tempkey. the input mode parameter determines the source of the key (the first 32 bytes of sha message) and challenge/nonce (the second 32 bytes of sha message). if keyconfig[keyid].re qrandom is one, the rng must have been used during the execution of the nonce command, or else this command will return an error. if authorization is required by the keyconfig before use of a key, this authorization function can be accomplished by executing this command with mode[1] set to zero. tempkey should have been previously loaded with a nonce via the nonce command. if keyconf ig[keyid].reqrandom is one, the rng should have been used during the execution of that nonce command. if the checkmac succeeds, then an internal authcomplete flag will be set and keyid retained internally. see section 4.4.8 , authorized keys for more details. if the comparison matches, then the target eeprom slot value may be copied into tempkey. if keyid is even, then the target slot is keyid+1, or els e the target slot is keyid. for the copy to take place the mode parameter to checkmac must have a value of 0x01 or 0x05 and slotconfig.readkey for the target key must be zero. this copy will take place regardless of the value of slotconfig.limiteduse for t he target slot. table 11 -3. input parameters name size notes opcode checkmac 1 0x28 param1 mode 1 bit 0: 0 = the second 32 bytes of the sha message are taken from the input clientchal parameter. 1 = the second 32 bytes of the message are taken from tempkey. bit 1: 0 = use key[keyid] in first sha block. 1 = use tempkey. bit 2: if mode:0 or mode:1 are set, then the value of this bit must match the value in tempkey.sourceflag or the comman d will return an error. bits 3 C 7: must be zero. param2 keyid 2 the internal key is to be used to generate the response. all except bits 0:3 of keyid are ignored. data1 clientchal 32 challenge sent to client. if mode:0 is one, then the value of this parameter will be ignored. (these 32 bytes must still appear in the input stream). data2 clientresp 32 response generated by the client. data3 otherdata 13 remaining constant data needed for response calculation. table 11 -4. output parameter name size notes result 1 returns a single byte with a value of zero if clientresp matches the internally computed digest; value of one if there is a mismatch. ATECC608A - preliminary ?2017 microchip technology page 67 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 the message that will be hashed with the sha - 256 algorithm consists of the following information: 32 bytes key[keyid] or tempkey (depending on mode) 32 bytes clientchal or tempkey (depending on mode) 4 bytes otherdata[0:3] 8 bytes zeros 3 bytes otherdata[4:6] 1 byte sn[8] 4 bytes otherdata[7:10] 2 byt es sn[0:1] 2 bytes otherdata[11:12] ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 68 ? 2017 microchip technology 11.3 counter command the counter command reads the binary count value from one of the two monotonic counters located on the device within the configuration zone. the maximum value that the counter may have is 2,097 ,151. any attempt to count beyond this value will result in an error code. the counter is designed to never lose counts even if the power is interrupted during the counting operation. in some power loss conditions, the counter may increment by a value of m ore than one. counter[0] may be attached to some keys to limit their use; counter [1] is never attached to any key. when counter[0] is attached to a key, the counter will be incremented with each use of the key until the counter has reached its maximum value at which point use of the key will no longer be permitted. the counter match function allows counter[0] incrementing to stop when the value in the counter matches the value in the config:countmatchkey eeprom key slot. countermatch is not supported fo r counter[1]. the number of legal uses for a key can also be controlled by initializing the counter[0] to a non - zero value at configuration time. contact microchip for details. table 11 -5. input parameters name size notes opcode counter 1 0x24 param1 mode 1 bit 0: 0 = read the value of the specified counter. 1 = increment the value of the specified counter. bit 1 - 7: must be zero. param2 keyid 2 the counter to be incremented. only zero and one are legal values. table 11 -6. output parameter name size notes count 4 or 1 generally, this will be the current binary value of the counter. if keyid points to in invalid counter id, a parse error will be returned. if a requested increment fails, then an exec error will be returned. ATECC608A - preliminary ?2017 microchip technology page 69 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 11.4 derivekey command the device combines the current value of a key with the nonce stored in tempkey using sha - 256 and places the result into the target key slot. slotconfig[targetkey].bit13 must be set or derivekey will return an error. derivekey always returns an error if ke yconfig indicates that the slot contains an ecc private key, if the configuration zone has not been locked, or if the targetkey slot is individually locked using slotlocked. if slotconfig[targetkey].bit12 is zero, the source key that will be combined with tempkey is the target key as specified in the command line (roll key operation). if slotconfig[targetkey].bit12 is one, the source key is the parent key of the target key, which is found in slotconfig[targetkey].writekey (create key operation). prior to ex ecution of this command, the nonce command must have been run to create a valid nonce in tempkey. if keyconfig.reqrandom is one for the source key, this nonce must have been created with the internal rng or an error will be returned. in all cases, mode:2 m ust match the state of tempkey.sourceflag or the command will return an error. if slotconfig[targetkey].bit15 is set, an input mac must be present and have been computed as follows: sha - 256(parentkey, opcode, param1, param2, sn[8], sn[0:1]) where the paren tkey id is always slotconfig[targetkey].writekey. if performing a roll key operation and keyconfig[targetkey].reqauth is one, then the appropriate authorization must have been performed using keyconfig[targetkey].authkey prior to the execution of derivekey . if performing a create key operation and keyconfig[parentkey].reqauth is one, then the appropriate authorization must have been performed using keyconfig[parentkey].authkey prior to the execution of derivekey. if an input mac is required and keyconfig[pa rentkey].reqauth is one, then the appropriate authorization must have been performed using keyconfig[parentkey].authkey prior to the execution of derivekey . if a parent key is involved in the operation (either slotconfig[targetkey].bit12 or slotconfig[targ etkey].bit15 are set) and slotconfig[parentkey].limiteduse is also set, derivekey returns an error if counter[0] has reached its limit. derivekey always ignores limiteduse for the target key. if the source and target key are the same, then there is a ris k of permanent loss of the key value if power is interrupted during the write operation. if the configuration bits permit it, then the key value may be recovered using an authenticated and encrypted write based on the parent key. table 11 -7. input parameters name size notes opcode derivekey 1 0x1c param1 mode 1 bit 2: the value of this bit must match the value in tempkey.sourceflag or the command will return an error. bits 0:1, 3:7: must be zero. param2 targetkey 2 key slot to be written. data mac 0 or 32 optional mac used to validate operation. ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 70 ? 2017 microchip technology table 11 -8. output parameter name size notes success 1 upon successful completion, the ATECC608A returns a value of zero. the key written to the target slot is the result of sha - 256 of the following message: 32 bytes target or parent key (depending upon slotconfig:bit 12) 1 byte opcode 1 byte param1 2 bytes param2 1 byte sn[8] 2 bytes sn[0:1] 25 bytes zeros 32 bytes tempkey.value the data flow for this command is illustrated below. figure 11 -1. data flow for derivekey command match p arent k e y t arget k e y sha ( a uth) input m a c sha (device) m od e s ou r ce k e y n on ce ATECC608A - preliminary ?2017 microchip technology page 71 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 11.5 e cdh command the ecdh command on the atecc508a computes the ecdh algorithm to create a shared secret. there are two possible sources for the private key: tempkey: the genkey command must have been previously executed to generate and load a new key into tem pkey. tempkey will be cleared after its use on the input but may be re - validated if it is the output target. eeprom key slot: the type of the slot must be an ecc private key. bit 2 in slotconfig.slotconfig.readkey for the private key must be set to enable the ecdh operation or this command will return an error. there are three possible destinations for the result, controlled by the mode parameter. output buffer: the output may be encrypted, see below. tempkey: any previous value in tempkey will be invalidated. the resulting tempkey can be used by the kdf or aes commands only. eeprom key slot: the target slo t must not be an ecc private key and must have the writeconfig field set to always. the target slot must not be slotlocked. the host processor may encrypt the premaster secret by executing an encrypted read of the target slot. if the target field of the mo de parameter is copy (00), then the chip operates in a manner compatible with the atecc508a: the result is place in either the output buffer or in the keyid | 1 slot depending on the value of the readkey field for the source key. in this case, the writecon fig check is suppressed. this is the only method to allow both the input and output to be the eeprom. if the mode byte indicates that the result should go to the output buffer then depending on the io protection configuration, various options are possible: ? if config.chipoption.ioprotenable is 0, then the result will be placed in the output buffer in the clear, regardless of the state of mode:bit 1 (output encryption) ? if config.chipoption.ioprotenable is 1, then the following possibilities occur: o if config.c hipoption.ecdhprot is 2 (store) then an error will be returned as the configuration prohibits the result on the output port o if config.chipoption.ecdhprot is 1 (encrypt) then the output will be encrypted regardless of the state of mode:bit 1 (output encrypt ion) o if config.chipoption.ecdhprot is 0 (clear) then the output will be encrypted if mode:bit 1 is set, otherwise it will be returned to the host in the clear. ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 72 ? 2017 microchip technology table 11 -9. input parameters name size notes opcode ecdh 1 0x43 param1 mode 1 bit 0: if 0, source key is eeprom slot. if 1, tempkey contains the private key bit 1: if 0, output is in the clear if permitted. if 1, force output encryption bit 2 - 3: 00 C compatibility copy mode. result goes to either the output buffer or keyid+1 depending on the state of config.slotconfig[keyid].readkey:3 01 C result goes to eeprom slot specified by keyid. config.slotconfig[keyid].writeconfig must be always (0000) 10 C result goes to tempkey 11 C result goes to the output buffer bits 4 - 7: reserved for future use, must be zero. param2 keyid 2 the private key to be used in the ecdh calculation if mode:0 is 0 data1 x 32 the x component of the public key to be used for ecdh calculation. data2 32 the component of the public key to be used for ecdh calculation. table 11 - 10. output parameter name size notes response 1 or 32 if the ecdh operation was successful and the destination is the output buffer, then this field contains the shared secret (pre - master secret). otherwise a success code of 0x00 or if any error has occurred, the error code. outnonce 0 or 32 if output is encrypted, the nonce used for the encryption output buffer encryption is implemented in the following manner: 1. the first 32 bytes of the io protection key slot (config.chipoption[bits 12 - 15]) are copied to a sha256 buffer. 2. the internal rng generates a 32 byte random nu mber (nonce) and appends only the first 16 bytes to the sha256 buffer 3. this sha256 buffer is hashed and the digest is xor?d with the cleartext pre - master secret. 4. the output buffer consists of the encrypted pre - master secret followed by the 32 byte nonce fro m step 2. note that the second 32 bytes of the nonce are ignored by the chip and are returned to the host for compatibility with the kdf encryption method only. ATECC608A - preliminary ?2017 microchip technology page 73 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 11.6 gendig command the gendig command uses sha - 256 to combine a stored or input value with the co ntents of tempkey, which must have been valid prior to the execution of this command. the stored value can come from one of the data slots, the configuration zone, either of the otp pages, the monotonic counters, or be retrieved from the hardware transport key array. the resulting digest is retained in tempkey, and can be used in one of four ways: 1. it can be included as part of the message used by the mac, sign or checkmac commands. because the mac response output incorporates both the data used in the gendig calculation and the secret key from the mac command, it serves to authenticate the data stored in the data and/or otp zones. 2. a subsequent read or write command can use the digest to provide authentication and/or confidentiality for the data, in which case it is known as a data protection digest. 3. the command can be used for secure personalization by using a value from the transport key array. the resultin g data protection digest would then be used by write. 4. the input value, typically a nonce from a remote device, is combined with the current tempkey value to create a shared nonce in which both devices can attest to the inclusion of the rng. if zone is two (i.e. data), and keyid is less than 0x8000 , then the gendig command sets tempkey.gendigdata to one, and tempkey.keyid to the input keyid; otherwise, tempkey.gendigdata is set to zero. if keyconfig.reqrandom is set for keyid, and the data zone is locked, th en the value in the tempkey register must have been originally computed using a random number via the nonce command; otherwise, gendig will fail. regardless of how the resulting digest is computed, it can never be read from the device. if tempkey.valid is invalid, this command returns an error. upon command completion, the tempkey.valid bit is set indicating that a digest has been loaded and is ready for use. the tempkey.valid bit is cleared when the next command is executed. see section 3.1 for more details. for all keyid values less than 0x8000 , the device uses the least - significant four bits of keyid to determine the sl ot number from which to retrieve the key value from the data zone of the eeprom. keyid values above 0x8000 reference keys stored in the masks of the design. these keys can only be used if the nonce value stored in tempkey has been generated using the on - board rng. in any event, all 16 bits of the keyid as input to the device are used as param2 in the sha - 256 c alculation. when the key specified on input to gendig has the nomac bit set, gendig can be used to generate ephemeral keys matching those generated on client cryptoauthentication devices using the derivekey command. keys which have the nomac bit set repres ent situations in which the device is acting as a host. in this case, the opcode and parameter bytes that would normally be included in the sha calculation are replaced with bytes from the input stream. ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 74 ? 2017 microchip technology table 11 - 11. input parameters name size notes opcode gendig 1 0x15 param1 zone 1 if 0x00 (config), then use keyid to specify any of the four 256 - bit blocks of the configuration zone. if keyid has a value greater than three, the command will return an error. if 0x01 (otp), use keyid to specify either the first or second 256 - bit block of the otp zone. if 0x02 (data), then keyid specifies a slot in the data zone or a transport key in the hardware array. if 0x03 (shared nonce), then keyid specifies the location of the i nput value in the message generation. if 0x04 (counter), then keyid specifies the monotonic counter id to be included in the message generation. if 0x05 (key config), then keyid specifies the slot for which the configuration information is to be included in the message generation. all other values are reserved and must not be used. param2 keyid 2 identification number of the key to be used, selection of which otp block or message order for shared nonce mode. data1 otherdata 32 or 4 or 0 four bytes of data for sha calculation when using a nomac key, 32 bytes for shared nonce mode, otherwise ignored table 11 - 12. output parameter name size notes success 1 upon successful execution, ATECC608A returns a value of zero. if zone is ?shared nonce? and keyid:15 is zero then the sha - 256 message body used to create the resulting new tempkey consists of the following bytes: 32 bytes input otherdata parameter 1 byte opcode (always 0x15) 1 byte mode 1 byte lsb of keyid 1 byte zero 1 byte sn[8] 2 bytes sn[0:1] 25 bytes zeros 32 bytes tempkey.value ATECC608A - preliminary ?2017 microchip technology page 75 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 if zone is ?shared nonce? and keyid:15 is one then the sha - 256 message body used to create the resulting new tempkey consists of the following bytes: 32 bytes tempkey.value 1 byte opcode (always 0x15) 1 byte mode 1 byte lsb of keyid 1 byte zero 1 byte sn[8] 2 bytes sn[0:1] 25 bytes zeros 32 bytes input otherdata parameter if zone is data and slotconfig[keyid].nomac is one, then the sha - 256 message body used to create the resulting new tempkey consists of the following by tes: 32 bytes data.slot[keyid] 4 bytes otherdata 1 byte sn[8] 2 bytes sn[0:1] 25 bytes zeros 32 bytes tempkey.value if zone is counter, then the sha - 256 message body used to create the resulting new tempkey consists of the following bytes. counter mode is supported only on the ATECC608A. 32 bytes zeros 1 byte opcode 1 byte param1 2 bytes param2 1 byte sn[8] 2 bytes sn[0:1] 1 byte zero 4 bytes counter[keyid] (binary value as reported by counter command) 20 bytes zeros 32 bytes tempkey.value if zone is ?key config? ( 0x05 ), then the sha - 256 message body used to create the resulting new tempkey consists of the following bytes: 32 bytes tempkey 1 byte opcode 1 byte mode 2 bytes param2 1 byte sn[8] 2 bytes sn[0:1] 1 byte zero 2 bytes slotconfig[keyid] 2 byt es keyconfig[keyid] 1 byte slotlocked:keyid 19 bytes zeros 1 byte 0x00 ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 76 ? 2017 microchip technology in all other cases, the message use to create tempkey is as follows: 32 bytes otp[keyid] or data.slot[keyid] or transportkey[keyid] 1 byte opcode 1 byte param1 2 bytes param2 1 byte sn [8] 2 bytes sn[0:1] 25 bytes zeros 32 bytes tempkey.value ATECC608A - preliminary ?2017 microchip technology page 77 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 11.7 genkey command the genkey command performs one or more of the following three operations: 1. private key creation: creates a new random private key. the private key will be written to tempkey if the keyid param is 0xffff. in this case, any previous contents of tempkey are destroyed. the resulting private key in tempkey can be used only by the ecdh command. otherwise th e genkey command writes the generated key into the slot specified by the keyid parameter. 2. public key computation: generates an ecc public key based upon the private key stored in the slot defined by the keyid parameter. this mode of the command may be us ed to avoid storing the public key on the device at the expense of the time required to regenerate it. 3. digest calculation: genkey can also combine a public key referenced by the keyid parameter with the current value stored in tempkey, calculate a sha - 256 digest of the resulting message, and place that digest back into tempkey. this digest can be used as the message for an internal signature, or as a component of a mac computation. tempkey must be valid prior to digest calculation. if keyconfig.reqrandom is set, then tempkey must have been created using the internal rng. the digest calculation operation can be performed by using eith er a public key computed from a private key in a slot or by using a public key already stored in a slot. in the latter case, the appropriate checks for prior authorization and limited u se will be performed on the public key slot, and the remaining checks i ndicated below will not be performed. when genkey is used to calculate a digest on a public key slot, it ignores the validity status of the public key. excluding the digest generation operation described above, the slot indicated by this command must be co nfigured by means of keyconfig.private to contain an ecc private key, and slotconfig.issecret must be set to one, or else this command will fail. if the keyconfig.keytype does not indicate an ecc curve supported by this device, then this command will also return an error. prior to the configuration zone being locked, this command will always return an error. once the data zone has been locked, the following additional restrictions are enforced: ? private key creation: ? bit 13 of the corresponding slotconfig mu st be set to one. ? if keyconfig.reqauth is set to one, then a prior authorization using keyconfig.authkey must have been performed. ? public key generation: ? keyconfig.genpub must be set to one. ? if keyconfig.reqauth is set to one, then a prior authorization us ing keyconfig.authkey must have been performed. the following applies to all private key creation operations regardless of whether or not the data zone has been locked: ? this command writes only those bytes necessary to create a private key of the type spec ified. the remaining bytes within the slot are unaffected by this command. ? when creating and writing a random key into the data zone, the genkey command always returns the public key regardless of the value of the genpub bit within the keyconfig area. ? if t he corresponding slotlocked bit is zero, then this command returns an error. ? there is a small statistical probability that the generated key will be unacceptable, in which case this command will return a single byte containing the ecc fault code (see table 10 - 3 , status/error codes in four byte groups ). in this circumstance the command should be re - run and will usually generate a key correctly in the s ubsequent iteration. ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 78 ? 2017 microchip technology table 11 - 13. input parameters name size notes opcode genkey 1 0x40 param1 mode 1 see below. param2 keyid 2 data otherdata 3 if keyid points to a public key, then these bytes replace param1 and param2 in the message calculation. table 11 - 14. output parameter name size notes response 1 or 64 public key x and y coordinates. ecc fault code if generated private key was unacceptable. table 11 - 15. mode encoding bits meaning 0 C 1 must be zero. 2 1 : a random private key is generated and stored in the slot specified by keyid. keytype must indicate an ecc key in the keyconfig area for this keyid or an error will be returned. 0 a the private key currently stored in the slot is used to generate the pu blic key. 3 1 : the device creates a pubkey digest based on the private key in keyid and places it in tempkey. 0 : no pubkey digest is created. 4 1 : keyid must point to a public key, and genkey only creates the digest in tempkey without any public key generation operation. bit 2 and bit 3 of the mode byte are ignored if this bit is set. 0 : keyid points to a private key, and mode:2 and mode:3 control device operation. 5 C 7 must be zero. when a pubkey digest is to be calculated by the genkey command, the following message is used as the input to the sha - 256 algorithm: 32 bytes tempkey 1 byte opcode 1 byte param1 2 bytes param2 1 byte sn[8] 2 bytes sn[0:1] 25 bytes zeros 64 bytes x and y coordinates of the public key ATECC608A - preliminary ?2017 microchip technology page 79 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 11.8 info command info command accesses some static or dynamic four byte information from the device depending upon the value of mode. illegal values of the mode parameter will result in a parse error response. table 11 - 16. mode encoding param1 mode notes 0 revision a single 4 - byte word representing the revision number of the device is returned. software should not depend on this value as it may change from time to time. 1 keyvalid returns a value of one if an ecc private or public key stored in the key slot specified by param is valid and zero if the key is not valid. for public keys in slots where pubinfo is zero, the information returned by this command is not useful. this information is not meaningful for slots in which keytype does not indicate a supported ecc curve. 2 state returns various dynamic state information as follows: first byte on the bus: bits 0 C 3 tempkey.keyid bit 4 tempkey.sourceflag bit 5 tempkey.gendigdata bit 6 tempkey.genkeydata bit 7 tempkey.nomacflag second byte on the bus: bit 0 0 bit 1 0 bit 2 authvalid: a valid authorization sequence has been performed. bit 3 C 6 authkey: the slot id on which an authorization was performed. bit 7 tempkey.valid the third and fourth bytes on the bus are all zeros. 3 gpio accesses the gpio pin when the device is in either of the single - wire interface modes. the specific operation is controlled by param2 as follows: bit 0 state to which output is to be driven. ignored if bit 1 is zero. bit 1 driver state; input (0) or output (1). bi ts 2 - 15 must be zero. always return the current state in the first byte followed by three bytes of 0x00 . 4 volatile key permit if param2:bit 1 is 0, then return the current state of the persistent latch. if param2:bit 1 is 1 and config.volkeypermit:bit 7 is set, then write param2:bit 0 to the persistent latch only if a valid authorization operation has been previously executed using the key specified at config.volkeypermit:bits 0 - 3 table 11 - 17. input parameters name size notes opcode info 1 0x30 param1 mode 1 see above. param2 param 2 use depends on mode. data 0 ignored. ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 80 ? 2017 microchip technology table 11 - 18. output parameters name size notes response 4 the information specified by mode or an error code. further information on the gpio mode is as follows: ? if the io_mode field within config. i2c_address is set to disabled, or if config:i2c_enable:bit 0 is set to i 2 c mode, then the gpio mode always returns an error code to the system firmware. ? if the io_mode field within config.i2c_address is set to authorization modes, then the operation depen ds on i2c_address:bit 3. if this bit is zero, then the device is in authorization output mode. if one, then the device is in intrusion detection mode. ? authorization output mode : regardless of the state of param2:bit1, on a successful execution the info c ommand returns the current state of the output pin. if param2:1 indicates output and param2:0 matches the default output state (i2c_address:2), then set the output to the default; otherwise, if authvalid is one and authkey matches signalkey, then set the o utput to the opposite of the default state. ? intrusion detection mode : regardless of the state of param2:bit1 on a successful execution the info command returns the current state of the persistent latch. if param2:1 indicates output, and if authvalid is on e and authkey matches signalkey, then set the persistent latch to param2:bit 0. ? if the io_mode field within config.i2c_address is set to input, then the current state of the gpio pin is returned to the system firmware without changing the direction of the gpio pin. this command will return an error if param2:bit 1 (driver state) is set to one (output). ? if the io_mode field within config.i2c_address is set to output, then the direction of the gpio driver will be set to match param2:bit 1 to zero for input a nd one for output. if configured as an output, then the value in param2:bit 0 will be driven to the pin. regardless of the value in param2, the current state of the gpio pin will be returned to the system in the output response parameter. ATECC608A - preliminary ?2017 microchip technology page 81 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 11.9 kdf command the kdf command implements one of a number of key derivation functions (kdf). generally this function combines a source key with an input string and creates a result key/digest/array. three algorithms are currently supported: prf, hkdf and aes. prf: the kdf specified in tls 1.2 and earlier used for session establishment. the chip supports multiple variations including the methods used for master secret generation, session validation (finished messages) and key material generation (including aead suites) aes: as used in some protocols. calculates aes on a single block of input data, result is the key. upper 16 bytes of the output are padded to 0 so the result is always 32 bytes. hkdf: the kdf currently specified for tls 1.3. the input key may be e ither tempkey, the alternate key buffer or an eeprom slot. in either case, the length of the input storage location may be 32 or 64 bytes, though the actual kdf mode may also use only 16 or 48 for the cryptographic key depending on the algorithm. the outpu t result of the kdf, which could be 32 or 64 bytes, can be returned to the system in the output buffer, written to tempkey or the alternate key buffer, or stored in an eeprom slot. a 32 byte kdf result can be written to the upper 32 byte area of tempkey on ly if the lower 32 byte area is already valid. if the output is returned to the system in the output buffer, then it may be encrypted depending on the mode parameter. if the prf_prot field in config.chip_options is encrypt, then the output will be encrypte d regardless of the input mode. if the prf_prot field in config.chip_options is store, then the output must go to either tempkey or the eeprom. if an output is encrypted, it is always followed by a 32 bytes nonce. the target can be written to the eeprom on ly if keyconfig[keyid].type is data and keyconfig[keyid].pubinfo is 1 and slotconfig[keyid].writeconfig is ?always?. param1 and param2 control the source and destination of the kdf operation and are common for all three methods. since there are different c omputation methods for each method, there is a third param3 (details) which drives the inner computation phase. following the details parameter is any data necessary for the calculation. table 11 - 19. input parameters name size notes opcode kdf 1 0x56 param1 mode 1 controls the key source and target location for the kdf function. param2 keyid 2 slot locations in eeprom if source or target is in the eeprom param3 details 4 further information about the computation, depending on the algorithm. see below. data message <128 input value from system ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 82 ? 2017 microchip technology table 11 - 20. output parameter name size notes outdata 1, 32, 64 the output of the kdf function or a success code if the result remains within the device. outnonce 0, 32 if the output is encrypted, a 32 byte random nonce generated by ATECC608A table 11 - 21. mode encoding bits meaning 0 C 1 source for the kdf input key: 0: get the kdf key from tempkey, length will be 32 or 64 bytes 1: get the kdf key from the upper block of tempkey, length will be 32 bytes 2: get the kdf key from an eeprom slot. use the ls byte of the keyid input parameter 3 : get the kdf key from the alternate key buffer. 2 C 4 target for the kdf result: 0: write the kdf result to tempkey 1: write the result to the upper block of tempkey, do not affect the lower block 2: write the kdf result to an eeprom slot. use the ms byte of the keyid input parameter 3: write the result to the alternate key buffer 4: place the kdf result in the output buffer. it will be in the clear if config.chipoptions permits 5: place th e kdf result in the output buffer encrypted with the io protection key 5- 6 algorithm: 0 is the tls prf. 1 is aes. 2 is hkdf. 3 is reserved. 7 must be 0 table 11 - 22. detail parameter encoding for prf bits name description 0 C 1 keylen the length of the source key in 16 byte blocks. 0 = 16 bytes, 1 = 32 bytes, 2 = 48 bytes, 3 = 64 bytes 2 C 7 zero must be zero 8 targetlen the number of 32 byte blocks to be placed in the target location. 0 = 32 bytes, 1 = 64 bytes 9- 10 aead if 00, no special aead processing. if 10, generate 96 bytes, shift down and ignore first 32 bytes. result is (targetlen+1) * 32 of the bytes that remain if 11, generate 96 bytes, shift down 32 bytes. first 32 remaining go to target, second 32 remaining go to output, never encrypted. do not use this mode if output destination is the output buffer, use 10 instead. 11- 23 zero must be zero 24- 31 datalen length in bytes of the input parameter (label | seed in tls lingo) ATECC608A - preliminary ?2017 microchip technology page 83 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 table 11 - 23. detail parameter encoding for aes bits name description 0 C 1 keyloc the aes key is located at src[keyloc*16] within the source key material. if the source key is only 32 bytes then keyloc must be either 0 or 1. 2 C 31 zero must be zero the hkdf function within the kdf command is intended to support the necessary key derivation operations as specified in tls 1.3 and other protocols. if the special iv function is indicated in the msgloc field of the detail parameter, then the message in the input buffer will be checked to ensure that it contains the appropriate string t o be considered an iv calculation. if the two bytes starting at index config.kdfivloc match the two stored at config.kdfivstr, this mode allows the output restrictions to be ignored and the result to be returned in the clear. also see section 2.2.7 . it is possible to specify that all three of the input key, the message and the output key point to tempkey. this combination is forbidden and the results may be unpredictable. table 11 - 24. detail parameter encoding for hkdf bits name description 0 C 1 msgloc the location of the message. 0 = eeprom slot, 1 = tempkey, 2 = input parameter, 3 = special initialization vector function 2 zerokey if 1, the key is 32 bytes of 0 3 C 7 zero must be zero 8- 11 msgkey the key slot for the message if in eeprom 12- 24 zero must be zero 25- 31 datalen length in bytes of the hkdf message . if this value is zero, then the message will be 32 bytes of 0. for all algorithms, output buffer encryption is implemented in a manner similar to the ecdh command, as below. if the io protection function is not enabled (config.chipoption[bit 1]) then ATECC608A will return an error if output encryption is indicated in the mode parameter. 1. the fir st 32 bytes of the io protection key slot (config.chipoption[bits 12 - 15]) are copied to a sha256 buffer. 2. the internal rng generates a 32 byte random number and appends the first 16 bytes of that nonce to the sha256 buffer 3. the sha256 buffer is hashed and th e digest is xor?d with the first 32 bytes of the cleartext kdf result. if there are only 16 bytes in the result, then the output buffer will contain only those 16 bytes and the second 16 bytes of the sha digest will be ignored. 4. if there are more than 32 by tes in the output, then a new digest is created via the sha256 hash of the io protection key (32 bytes) followed by the second 16 bytes of the random nonce from step #2. the resulting digest is xor?d with the next 32 bytes of the result. ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 84 ? 2017 microchip technology 5. the output buffer consists of the encrypted kdf result followed by the 32 byte nonce. all 32 bytes of the nonce are output even if only the first 16 have been used. ATECC608A - preliminary ?2017 microchip technology page 85 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 11.10 lock command the lock command prevents future modifications of the configuration and/or data and otp zones. if the device is so configured, then this command can be used to lock individual data slots. this command fails if the designated area is already locked. prior to lockin g the configuration and/or data and otp zones, the ATECC608A can optionally use the crc - 16 algorithm to verify the contents of the designated zone(s). the calculation uses the same algorithm as the crc computed over the input and output groups. this summar y digest (crc) is always ignored when locking an individual slot. ? configuration zone : the crc is calculated over all 128 bytes within the configuration zone using the current value of the lockconfig at address 87. if the compare succeeds, then lockconfig w ill be set to a value of 00 . ? data and otp zone : the slot contents are concatenated in numerical order to create the input to the crc algorithm. slots that are configured to contain an ecc private key are never included in the summary crc calculation. the o tp zone is then concatenated after the last data slot and the crc value is calculated. if the compare succeeds, then lockvalue will be set to a value of 00 . if mode:7 is zero and the input summary does not match that computed on the device, then an error i s returned and the personalization process should be repeated. for slots containing public keys that must be validated, the most significant four bits are modified by the device when being written and/or when being validated. the summary crc is calculated using the current values. table 11 - 25. input parameters name size notes opcode lock 1 0x17 param1 mode 1 see table 11 - 27 . param2 summary 2 summary (crc) of the designated zones, or should be 0x0000 if mode:7 is set. data ignored 0 table 11 - 26. output parameter name size notes success 1 upon successful execution, ATECC608A returns a value of zero. table 11 - 27. mode encoding bits meaning 0 C 1 0 : the configuration zone is to be locked. 1 : the data and otp zones are to be locked. 2 : a single slot in the data zone is to be locked. 3 illegal value, the device will return an error. 2 C 5 the slot number to be locked if bits01 have a value of two otherwise, these bits must be ero. 6 unused, must be ero. 7 summary check bit. this bit is ignored when locking individual data slots. 0 : the summary value is verified before the zone is locked. ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 86 ? 2017 microchip technology bits meaning 1 : check of the zone summary is ignored and the zone is locked regardless of the contents of the zone. microchip does not r ecommend using this mode. 11.11 mac command the mac command computes a sha - 256 digest of a key stored in the device, a challenge, and other information on the device. the output of this command is the digest of this message. if the message includes the serial n umber of the device, the response is said to be ?diversified?. the normal command flow to use this command is as follows: 1. run nonce command to load input challenge and optionally combine it with a generated random number. the result of this operation is a nonce stored internally on the device. 2. optionally, run gendig command to combine one or more stored eeprom locations in the device with the nonce. the result is stored internally in the device. this capability permits two or more keys to be used as part of the response generation. 3. run this mac command to combine the output of step one (and step two if desired) with an eeprom key to generate an output response (i.e. digest). alternatively, data in any slot (which does not have to necessarily even be secret) can be accumulated into the response through the same gendig mechanism. this has the effect of authenticating the value stored in that location. table 11 - 28. input parameters name size notes opcode mac 1 0x08 param1 mode 1 controls which fields within the device are used in the message. param2 keyid 2 the internal key is to be used to generate the response. bits 0:3 only are used to select a slot; however, all 16 bits are used in the sha - 256 message. data challenge 0 or 32 input portion of message to be digested, ignored if mode:0 is one. table 11 - 29. output parameter name size notes response 32 sha - 256 digest the message that will be hashed with the sha - 256 algorithm consists of the following information: 32 bytes key[keyid] or tempkey (see mode encoding ) 32 bytes challenge or tempkey (see mode encoding ) 1 byte opcode (always 0x08) 1 byte mode 2 bytes param2 8 bytes zeros 3 bytes zeros 1 byte sn[8] ( never zeroed out) 4 bytes sn[4:7] (or zeros, see mode encoding ) ATECC608A - preliminary ?2017 microchip technology page 87 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 2 bytes sn[0:1] ( never zeroed out) 2 bytes sn[2:3] (or zeros, see mode encoding ) table 11 - 30. mode encoding bits meaning 0 0 : the second 32 bytes of the sha message are taken from the input challenge parameter. 1 : the second 32 bytes are filled with the value in tempkey. this mode is recommended for all use. 1 0 : the first 32 bytes of the sha message are loaded from one of the data slots. 1 : the first 32 bytes are filled with tempkey 2 if either mode:0 or mode:1 are set, mode:2 must match the value in tempkey.sourceflag or the command will return an error. 3 C 5 must be zero. 6 1 : include the 48 bits sn[2:3] and sn[4:7] in the message; otherwise, the corresponding message bits are set to zero. 7 must be zero. ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 88 ? 2017 microchip technology 11.12 nonce command the nonce command generates a nonce for use by a subsequent command by combining an internally generated random number with an input value from the system. the resulting nonce is stored internally in tempkey and the generated random number is retu rned to the system. the input value is designed to prevent replay attacks against the host, and it must be externally generated by the system and passed into the device using this command. it may be any value that changes consistently, such as a nonvolatil e counter, current real time of day, and so forth, or it can be an externally generated random number. to provide a nonce value for subsequent crypto commands, the input number and output random number are hashed together according to the information liste d below. the resulting digest (i.e. nonce) is always stored in the tempkey register, tempkey.valid is set, and tempkey.sourceflag is set to rand . the nonce can then be used by a subsequent ATECC608A command. where the actual nonce value is required to be k nown by an external system, software will typically be needed to externally compute this digest value and store it externally to complete the execution of those commands. in order to simplify the system code for some usage models, the device provides a mec hanism for a host device to compute the nonce generated on a client device. in this calculation mode, the current value in tempkey is combined with the input parameters using sha and the result is written back into tempkey. the new tempkey value is also re turned to the system as the output parameter. mode:0 - 1 must have a value of zero or one to enable this feature. tempkey.sourceflag is not modified by the device in this mode. alternatively, this command can also be run in a pass - through mode if a fixed non ce is required for subsequent commands. in this case, the input value (either 32 or 64 bytes) is written directly to tempkey, the alternate key buffer or the message digest buffer without modification. no sha - 256 calculation is performed and tempkey.source flag is set to input (if writing to tempkey). if operated in this mode and with a repeated input number value, the device provides no protection against replay attacks. prior to the configuration zone being locked, the rng produces a value of 0xff ff 00 0 0 ff ff 00 00 to facilitate testing. this test value is combined with the input value in the manner described above. table 11 - 31. input parameters name size notes opcode nonce 1 0x16 param1 mode 1 controls the mechanism of the internal rng or fixed write as below. param2 zero 2 bits 0 - 14: must be zero. bit 15: 1 = randout is replaced by tempkey in both the hash calculation input (message) and the command output parameter. 0 = outdata is either the output of the rng or a single byte of zero. data numin 20, 32, 64 input value from system. ATECC608A - preliminary ?2017 microchip technology page 89 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 table 11 - 32. output parameter name size notes outdata 1 or 32 the output of the rng, calculated nonce or a single byte with a value of zero if mode[0:1] is three. if mode[0:1] is zero or one and param2:15 is zero, then the input numin parameter must be 20 bytes long and the sha - 256 message body used to create the nonce stored internally in tempkey consists of the following. upon completion of the command, tempkey.so urceflag is set to rand. 32 bytes randout from random number generator 20 bytes numin from input stream 1 byte opcode (always 0x16) 1 byte mode 1 byte lsb of param2 (should always be 0x00) if mode[0:1] is zero or one and param2:15 is one, then the inp ut numin parameter must be 20 bytes long and the sha - 256 message body used to create the nonce stored internally in tempkey consists of the following. tempkey must be valid prior to execution of this command and the values of the remaining tempkey flags re main unchanged. 32 bytes tempkey 20 bytes numin from input stream 1 byte opcode (always 0x16) 1 byte mode 1 byte lsb of param2 (should always be 0x00) if mode[0:1] is three, then this command operates in pass - through mode and tempkey is loaded with nu min. mode[5] determines whether 32 or 64 bytes are written to tempkey. no sha - 256 calculation is performed, no data is returned to the system, and tempkey.sourceflag is set to input. table 11 - 33. mode encoding bits meaning 0 C 1 0 or 1 : combine new random number with numin, store in tempkey. mode[5 - 7] are ignored. 2 : invalid. 3 : operate in pass - through mode and write target with numin. 2 C 4 must be zero. 5 if 0, then 32 bytes are written to the target.. if 1, then 64 bytes from the input will be written to the target which must be either tempkey or the message digest buffer. this bit is ignored unless mode[0:1] is pass - through 6- 7 target for the write. if 00, target is tempkey. if 01, target is the message digest buffer. if 10, target is the alternate key buffer. this field is ignored unless mode[0:1] is pass - through ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 90 ? 2017 microchip technology 11.13 privwrite command the privwrite command is used to write externally generated ecc private keys into the device. for best security, microchip recommends that the privwrite command not be u sed, and that private keys be internally generated from the rng using the genkey(create) command. the slot indicated by this command must be configured via keyconfig.private to contain an ecc private key, and slotconfig.issecret must be set to one, or else this command will return an error. if the slot is individually locked using slotlocked, then this command will also return an error. the private key data is always sent to the device as a 36 byte integer. it is passed to the device msb first. the first four bytes (32 bits) should be zero. prior to the data zone being locked, this command can be used to write the slot contents without regards to the slotconfig value and/or the method by which tempkey was generated. the input data may or may not be encrypted based on the zone byte; if the input data is plain text then the mac is ignored, but if it is en crypted then the mac must be present and be properly computed. prior to the configuration zone being locked, this command will always return an error. once the data zone is locked, the following is necessary for the write to complete: ? slotconfig.issecret must be one. ? slotconfig.writeconfig must be set to encrypt to indicate that writes require encryption. it is not possible to write to a slot for which writeconfig is set to any other value. ? tempkey must be valid, its contents must have been generated usin g the gendig command, and the keyid used during the gendig execution must match slotconfig.writekey. ? zone:6 must be set to indicate that the input data has been encrypted as follows: ? the first 32 input bytes should be externally encrypted by xoring their value with the current value in tempkey. the next four bytes should be externally encrypted by xoring their value with the first four bytes of sha - 256(tempkey). ? an input authenticating mac must be computed as follows: ? sha - 256(tempkey, opcode, param1, param 2, sn[8], sn[0:1], <21 bytes of zeros>, 36 bytes of plaintextdata) keyconfig.reqrandom, keyconfig.reqauth and keyconfig.authkey are ignored by this command because they will have been checked by the gendig command for the parent encrypting key. table 11 - 34. input param eters name size notes opcode privwrite 1 0x46 param1 one 1 bits 0 C 5, 7 must be ero. bit 6 1 = the input data is encrypted using tempkey. 0 = the input data is not encrypted: legal only when the data zone is unlocked. param2 keyid 2 key slot to be written. data_1 value 36 information to be written to the slot may be encrypted. must be 36 bytes long regardless of the size of the key. data_2 mac 32 message authentication code to validate eeprom write operation. ATECC608A - preliminary ?2017 microchip technology page 91 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 table 11 - 35. output parameter name size notes success 1 upon successful completion, ATECC608A returns a value of zero. 11.14 random command the random command generates a random number for use by the system. random numbers are generated via the internal nist 800 - 90 a/b/c random number generator. prior to the configuration zone being locked, the rng produces a value of 0xff, 0xff, 0x00, 0x00, 0xff , 0xff , 0x00, 0x00 to facilitate testing. table 11 - 36. input parameters name size notes opcode random 1 0x1b param1 mode 1 bit 0: ignored by the device bits 1 - 7: must be zero param2 zero 2 must be 0x0000 . data ignored 0 table 11 - 37. output parameter name size notes randout 32 the output of the rng. ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 92 ? 2017 microchip technology 11.15 read command the read command reads words (one four byte word or an 8 - word block of 32 bytes) from one of the memory zones of the device. the data may optionally be encrypted before being returned to the system. see section 10.5 for data zone byte and word addressing information. if reading from a slot in which slotconfig.encryptread is set, the gendig command must have been run prior to the execution of this command to generate the key that will be used for encryption. the key specified in slotconfig.readkey must have been used in the gendig calculation. the device encrypts data to be read by xoring each byte read from the eeprom with the corresponding byte from tempkey. encrypted reads of the configuration and/or otp zones are not permitted. keyconfig.reqrandom, keyconfig.reqauth, and keyconfig.authkey are ignored by this command because they will have been checked by the gendig command for the parent encrypting key. the byte addresses to be read should be divided by four (drop the least - significant two bits) before being passed to the device. if 32 bytes are being read, then the least - significant three bits of the input address are ignored. addresses beyond the end of the specified zone result in an error. the following restrictions apply to the three zones: ? configuration zone : the words within this zone are always readable using this command, regardless of the value of lockconfig. ? otp zone : if the otp zone is unloc ked this command returns an error. once locked, the entire otp zone may be read using 4 or 32 byte reads. ? data zone : if the data zone is unlocked, this command returns an error; otherwise, the values within the corresponding slotconfig word control access to the data slot. if slotconfig.issecret is set and a four byte read is attempted, the device returns an error. if encryptread is set, this command encrypts the data as specified above. if issecret is set and encryptread is clear, this command returns an error. if issecret is clear and encryptread is clear, this command returns the desired slot in the clear. partial data blocks are always zero extended to 32 bytes before being encrypted. table 11 - 38. input parameters name size notes opcode read 1 0x02 param1 zone 1 bits 0 and 1: select among configuration, otp, or data. see section 10.5 . bits 2 - 6: must be zero. bit 7: 1 = 32 bytes are read otherwise four bytes are read. param2 address 2 address of first word to be read within the one. see section 10.5 . data 0 table 11 - 39. output parameter name size notes contents 4 or 32 the contents of the specified memory location. ATECC608A - preliminary ?2017 microchip technology page 93 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 if reading a data zone and the encryptread bit is set in the corresponding slotconfig word, the following actions are taken to encrypt the data: ? all of the tempkey register bits must be properly set as follows or else this command returns an error: tempkey.valid == 1 tempkey.gendigdata == 1 tempkey.keyid == slotconfig.readkey tem pkey.sourceflag == rand ? xor the data from the memory zone with tempkey. return as contents . ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 94 ? 2017 microchip technology 11.16 secureboot command the secureboot command provides support for secure boot of an external mcu or mpu. the general approach is that the boot code within the sys tem will use the device to assist in validating the application code that is to be subsequently executed. ? the digest of all the code to be executed is sent to the chip along with a signature. this digest/signature pair is verified with a public key stored in the device and a boolean returned indicating success or failure. ? there is an option (mode == fullstore) to allow either the signature or verified digest to be stored in a slot within the chip to speed the boot time by limiting the io and/or computation times. this mode is enabled by setting config.sboot.method to 010 or 011. to use this mode, the host should initially execute a special fullcopy validation mode where the device receives both the digest and the signature. if the signature is verified, the n either the signature or digest is stored in the slot indicated by config.sboot.sigdig and the fullstore mode is then enabled. ? the slot to be written by fullcopy can be configured to require prior authorization to prevent certain kinds of denial of servic e attacks. the return code can be mac?d with a nonce from the host using the io protection secret to prevent tampering with the wire between the two devices. if so configured by setting securebootpersistentenable to one , the device can keep various keys disabled on power - up until a proper secure boot operation has completed, after which they will continue to be usable until the next time power is lost even if the device goes to sleep during the power cycle . this is accomplished via the persistentdisable b it in keyconfig and the persistent latch which maintains its state even when ATECC608A enters sleep mode. if the device is configured to disable keys on power - up until a proper secu re boot operation has completed but a successful secure boot has not yet co mpleted during this power cycle, the secureboot command can be locked out until the next power cycle by setting bit 6 in the mode byte. this bit is ignored if a successful secure boot has completed or if securebootpersistentenable is zero. table 11 - 40. input parameters name size notes opcode secureboot 1 0x80 param1 mode 1 bits 0 - 2: see table below. all values not listed in the table are forbidden. bits 3 - 5 : must be zero bit 6: if 1, then the secure boot function may be prohibited until the next power cycle. bit 7 : if 1, the input digest should be encrypted and a validating mac will be appended to the output. if config.sboot.randnonce is set, then this bit is required for modes validate, full, fullcopy and fullstore. it must not be set for the remaining modes. pa ram2 param2 2 must be zero data data 32, 96 depends on mode: full, fullcopy: 32 byte digest of entire code image followed by 64 byte signature to be verified by public key at config.sboot.pubkey. code digest is encrypted if mac is requested. fullstore: 32 byte digest of entire code image. code digest is encrypted if mac is requested. ATECC608A - preliminary ?2017 microchip technology page 95 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 table 11 - 41. output parameters name size notes errorcode 1 if 0, the comparison completed successfully and resulted in a match. if 1, the computation completed, but the value submitted was a mismatch. other error codes indicate other issues with the command encoding, math computation, etc. mac 0 or 32 if an output mac is indicated then mac calculated as below if match is 1 (validation succeeded). if the input mode parameter specifies that a mac is not required, then this parameter is zero length. table 11 - 42. mode encoding value name meaning 0- 4 reserved reserved, do not use these values 5 full verify an input code digest of the entire code image using a signature in the input stream and a public key indicated by config.sboot.pubkey. a mac may optionally replace the output on success. 6 fullstore verify an input code digest of the entire code image using a signature or digest stored in a key slot and a public key (if requ ired) indicated by config.sboot.pubkey. a mac may optionally replace the output on success. 7 fullcopy identical to full, except that either the digest or signature is copied to the target slot on successful validation if a mac is allowed by the mode parameter and the mac request bit is set, there are no parse or execution errors and the digest is accepted via either a signature verify or saved digest match, then neither the error code nor the match byte will be returned, instead the 32 byte mac will b e in the output parameters. the host software should make sure to check the count of returned bytes as the first byte of the mac may be any value from 0x00 through 0xff and this will not, by itself, indicate any status, as below. if the mode indicates that a mac is to be calculated, then the input code digest (aka message) will be encrypted by xoring with the sha256 digest of the io protection key concatenated with the nonce stored in tempkey. if config.secureboot.securebootrandnonce is set, then tempkey mu st have been generate by the nonce command using the random mode. this io protection key/tempkey digest is then re - used as part of the output mac calculation as indicated below. if a validation mac is to be computed by the device in full, fullcopy or fulls tore(sig) code modes, the nonce command must have been run in advance to ensure that a nonce is available in tempkey. if the config.secureboot.randnonce bit is set, then the nonce command must have been run in a mode that requires the inclusion of the atec c608a rng. the mac will be computed as the sha - 256 digest of the following message: ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 96 ? 2017 microchip technology 32 bytes contents of the io protection key 32 bytes nonce. first 32 bytes of tempkey compute sha256 digest of above two elements, xor digest with input encrypted code diges t (message) to create plaintext code digest 32 bytes digest of io protection key and nonce, as previous line 32 bytes plaintext message. first 32 bytes of input buffer 64 byte signature as passed input buffer or from slot, per mode 4 bytes input parameters (opcode, mode, param2) if a validation mac is to be computed by the device in fullstore(dig), the nonce command must have been run in advance to ensure that a nonce is available in tempkey. the mac will be computed as the sha - 256 digest of the following message: 32 bytes contents of the io protection key 32 bytes nonce. first 32 bytes of tempkey compute sha256 digest of above two elements, xor digest with input encrypted code digest (message) to create plaintext code digest 32 bytes digest of io protectio n key and nonce, as previous line 32 bytes plaintext message. first 32 bytes of input buffer 4 bytes input parameters (opcode, mode, param2) ATECC608A - preliminary ?2017 microchip technology page 97 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 11.17 selftest command perform a test of one or more of the cryptographic engines within the ATECC608A chip. some or all of the algorithms will be tested depending on the input mode parameter. the config.chipoption.powerupselftest bit can be set in the eeprom in which case the sha, aes and rng tests will always be run on a power - up or wake from sleep. the chip cannot be configured to automatically run the ecc functions automatically on wake/power - up. if any self test fails, whether called automatically on wake or via this command, the chip will enter a failure state in which chip operation is limited. the stored failure s tate is always cleared upon a wake or power cycle. when in the failure state, the following operations are allowed: ? reads of the configuration zone ? this self test command. if a particular test is re - run and passes on the subsequent attempt, that bit in the failure register will be cleared. if all bits are cleared, then ATECC608A resumes normal command operation. ? the current state of the failure register can be read by calling this self test command with a mode parameter of 0. ? any other command, or reads of any other zone, will return an error code of 0x07. use selftest(0) to determine the cause of the failure table 11 - 43. input parameters name size notes opcode selftest 1 0x77 param1 mode 1 bit 0: if 1, test the rng drbg function bit 1: if 1, test the ecdsa verify function bit 2: if 1, test the ecdsa sign function bit 3: if 1, test the ecdh function bit 4: if 1, test the aes function C encrypt only bit 5: if 1, test the sha function bits 6 - 7: must be zero more than 1 bit may be set. to test all algorithms, the mode parameter should be 0x3f. if mode is 0, then return the current value of any stored failures this power cycle. param2 param2 2 must be zero. table 11 - 44. output parameter name size notes response 1 if 0, then all the requested tests were run without failure. if non - zero, then a bit map of the failing tests encoded in the same manner as the mode parameter where a 1 indicates that the test failed. ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 98 ? 2017 microchip technology 11.19 sha command computes a sha - 256 or hmac/sha digest for general purpose use by the host system. the sha computation is performed in a special section of internal atecc508a memory that is not read or written by any other commands. any arbitrary command can be interspersed between the various phases of the sha command without problems. this stored sha context is invalida ted on power - up. in most cases, if an error occurs during the execution of the sha command, the context is retained without change. calculation of a sha/hmac digest occurs as follows: ? start : initialization of the sha - 256 calculation engine and initializat ion of the sha context in memory. this mode does not accept any message bytes. ? hmac_start : initialization of the sha context in memory and initial hmac calculation using a stored 32 - byte key. the key must be configured to be legal for use with mac operati ons and is specified in the keyid parameter. if keyid is 0xffff, then the hmac key will be taken from tempkey. this mode does not accept any message bytes. this mode does not support key lengths other than 32 bytes. ? update : the command can be called a var iable number of times with this mode to add bytes to the sha or hmac message. each iteration of this mode must include a message of 1 - 64 bytes. there is a variation on update which adds 64 bytes of a stored public key to the context. ? end : the sha - 256 or h mac calculation is completed and the resulting digest is placed into the output buffer. the stored sha context is invalidated on a successful ?end? command. if so specified in the mode parameter, the digest and also be copied into either tempkey or the mes sage digest buffer. from 0 through 64 bytes may be passed into the command as the final message bytes to be used before the digest is calculated. if the sha context was started with hmac_start, then the hmac calculation is completed using the key id passed to the hmacstart phase and the resulting digest is placed into the output buffer. the key is re - loaded from the ecc 608a memory during this calculation and the result will be incorrect if any changes to the key storage location occurred between the hmac_st art and end phases. the stored sha context can be offloaded from the chip (read_context) and stored in host memory to permit multiple sha digests to be calculated concurrently. the context stored in host memory can later be written back to the atecc 608a multiple times or just once. the context can be read after the init or update modes, but can no longer be read once the end phase has been executed. the host should not manipulate the stored context in any way or the results may be incorrect. ? read_contex t : reads a variable length context from the atecc 608a while leaving the context valid within the chip. the total length of the output data parameter is always from 40 to 99 bytes and can be determined either from the length field in the output packet or c omputed as 40 plus the least significant six bits of the first byte in the output. this mode is not permitted for hmac contexts, i.e. if the context was initialized with hmac_start or if a public key has been added to the context via the public mode. ATECC608A - preliminary ?2017 microchip technology page 99 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 ? write _context : write a sha256 context from the host to the atecc 608a to allow subsequent update operations to be completed. this context should have previously been read from the chip with the read_context mode. ATECC608A determines the size of the context fro m the first 4 bytes of the data parameter, which should have been generated by the read_context command. this command can also optionally generate a digest to be used by verify(validateexternal) to validate a stored public key, which allows speed - up for f uture signature validations when x.509 format signatures are used. to implement this, a sha(public) iteration can be inserted prior to sha(end) iteration, and the 64 bytes of the public key stored in the slot designated by param2 will be added to the messa ge. this mode will fail if the designated slot does not contain a public key or if slotconfig.nomac is set for the public key slot. verify(validateexternal) will only successfully validate the stored public key if the sha(public) iteration occurs at the at the block number indicated by config.publicposition (x509format:0 - 3) within the sequence of sha(update) commands, and if the total number of blocks passed to the sha command matches the value in config.templatelength (x509format:4 - 7). this restriction pre vents a generation of non - standard x.509 templates, which may push the inserted public key into an unchecked area of the template. for implementation reasons, this sha command is limited to a total message length of 2 28 bytes. table 11 - 45. input parameters name size notes opcode sha 1 0x47 param1 mode 1 bits 0 - 2 see table below. all values not listed in the table are forbidden. bits 3 - 5 must be ero bits 6 - 7 ignored except for finalie, when it is interpreted as 00 place resulting digest in both output buffer and tempkey 01 place resulting digest in both output buffer and message digest buffer 10 do not use 11 place resulting digest in output buffer only param2 length 2 keyslot for the hmac key if mode is hmacstart or public key if mode is pub lic data message 0C 64, 40 - up to 64 bytes of data to be included into the update or finalie mode operation. if writecontext, up to bytes should be provided. table 11 - 46. output parameter name size notes response 1 or 32 or 40- 99 the sha256 digest if mode is one of the finalize modes, otherwise zero for success or an error code. from 40 to 99 bytes if read_context ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 100 ? 2017 microchip technology table 11 - 47. sha mode encoding name bits 0- 2 notes initialize 0 initialize the internal sha256 context memory. no message bytes are accepted (length must be zero). update 1 add 1 - 64 bytes in the message parameter to the current sha context in memory finalize 2 complete the sha - 256 or hmac computation and place the digest into the output buffer. optionally include 1 - 64 bytes in the context before the finalize. public 3 add 64 bytes of a public key from an eeprom slot into the context hmac_init 4 load the internal sha context with the ini tialization value for hmac(sha - 2 56), read the hmac key and hash that into the context. length field specifies the key to be used for the hmac calculation, 0xffff means use tempkey. no message bytes are accepted (length must be zero). read_context 6 read the current context out of the device to be stored in host memory. write_context 7 write (restore) a context into the atecc508a context memory. bytes written should have come from a read_context command output. ATECC608A - preliminary ?2017 microchip technology page 101 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 11.20 sign command the sign command generates a signature using the ecdsa algorithm. the ecc private key in the slot specified by keyid is used to generate the signature. the message may be externally or internally generated, as noted below: ? e xternal message generation (mode:7 is 1 ) ? the system should externally compile the information to be signed and compute the digest of that information using an external hash algorithm. this digest should then be loaded into tempkey or the message digest buffer using the nonce command. ? external signatures must be enabled using slotconfig.readkey:0 or else this command will return an error. ? internal message generation (mod e:7 is 0 ) ? the message to be signed is internally generated. a typical use for this mode is to sign an internally generated random key. ? the message is comprised of the output of the gendig or genkey commands (stored in tempkey), plus various other state inf ormation according to the description below. if tempkey is invalid or if it was not generated using gendig or genkey , then this command will return an error. ? internal signatures must be enabled using slotconfig.readkey:1 or this command will return an err or. ? if the data zone has not been locked, then internal signatures will always generate an error code. the slot indicated by this command must be configured via keyconfig.private to contain an ecc private key, and slotconfig.issecret must be set to one or else this command will fail. the chip ignores keyconfig.reqrandom when executing this command. if the mode indicates that the message was internally generated, the gendig or genkey commands will have interrogated the corresponding reqrandom bit and retu rned an error if tempkey as input to those commands was not derived from the rng source. there is a small statistical probability that the device will fail to properly generate the ephemeral key, in which case this command will return a single byte contain ing the ecc fault code (see table 10 - 3 , status/error codes in four byte groups ). the command will generally succeed if resubmitted. table 11 - 48. input parameters name size notes opcode sign 1 0x41 param1 mode 1 see below. param2 keyid 2 the internally - stored private key to be used to generate the signature. the curve specified in keyconfig[keyid].keytype will be used. table 11 - 49. output parameter name size notes response 64 the signature composed of r and s, or an error code. ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 102 ? 2017 microchip technology table 11 - 50. mode encoding bits meaning 0 set to 0 if the resulting signature is intended to be used by verify(validate) or one if it is to be used by verify(invalidate) . in all other situations, this bit must be zero. 1 C 4 must be 0 . 5- 7 1 00x: generate an internal message to be signed from the current value in tempkey in addition to key slot configuration information as below. set the sn bits to 0 01x: generate an internal message as below and include the stored 48 bit serial number (sn[2:3] and sn[4:7]) 1x0: the message to be signed is in tempkey 1x1: the message to be signed is in the message digest buffer note 1: the ?x? in this field indicates that the mode bit can be either 0 or 1 internal signat ures are generated over a 55 byte message consisting of the information listed below. the first element of the message is the public key digest information placed in tempkey by genkey or gendig . the message also includes configuration information regarding the key used for the tempkey calculation. this 55 byte message is created as follows: if multiple genkey or gendig commands have been run between the nonce and sign commands, only the configuration for the last key used will be signed. the bit within the slotlocked field corresponding to the last key used in the tempkey computation is in the lsb of the byte listed below, regardless of whether or not the slot is individually lockable or not. if the slot contains a public key correspondin g to a supported curve, and if pubinfo indicates this key must be validated before being used by verify , and if the validity bits have a value of 0x05 , then the pubkey valid byte will be 0x01 . in all other cases, it will be 0 . 32 bytes tempkey (must have been generated by genkey or gendig) 1 byte opcode 1 byte mode 2 bytes param2 2 bytes slotconfig[tempkeyflags.keyid] 2 bytes keyconfig[tempkeyflags.keyid] 1 byte tempkeyflags (b0 - 3: keyid, b4: sourceflag, b5: gendigdata,b6: genkeydata, b7: nomacflag) 2 b yte zeroes 1 byte sn[8] ( never zeroed out) 4 bytes sn[4:7] (or zeros, see mode) 2 bytes sn[0:1] ( never zeroed out) 2 bytes sn[2:3] (or zeros, see mode) 1 byte slotlocked:tempkeyflags.keyid 1 byte pubkey valid (or zero, see above) 1 byte 0x00 this mess age is then hashed using the sha - 256 algorithm and passed to the ecdsa signature comp utation engine. ATECC608A - preliminary ?2017 microchip technology page 103 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 11.21 updateextra command the updateextra command is used to update the values of the two extra bytes within the configuration zone (location 84 and 85) after the configuration zone has been locked. for i 2 c chips, byte 85 bay be used as the i2c address, depending on the state of config.chipmode.b it0. these bytes are essentially one - time write bytes: once they are written to a non - cero value they can no longer be written. ? if the mode parameter indicates userextra at address 84: ? if the current value in userextra (byte 84 of configuration zone) is ze ro, then updateextra writes this byte with the ls byte of newvalue and returns success. ? if the current value in userextra is non - zero, then the command returns an execution error. ? if the mode parameter indicates userextraadd at address 85: ? if the current value in userextraadd (byte 85 of configuration zone) is zero, then updateextra writes this byte with the ls byte of newvalue and returns success. ? if the current value in userextraadd is non - zero, then the command returns an execution error. table 11 - 51. input paramet ers name size notes opcode updateextra 1 0x20 param1 mode 1 bit 0: 0 = update config byte 84. 1 = update config byte 85. bits 1 C 7: must be zero. param2 newvalue 2 lsb: value to optionally be written to location 84 or 85 in configuration zone. msb: must be 0x00 . data 0 table 11 - 52. output parameter name size notes success 1 if the memory byte was updated, this command returns a value of 0x00 ; otherwise, it returns an execution error. ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 104 ? 2017 microchip technology 11.22 verify command the verify command takes an ecdsa [r,s] signature and verifies that it is correctly generated given an input message digest and public key. in all cases, the signature is an input to the command. an optional mac can be returned from the verify command to defeat any man - in - the - middle attack. if the verify calculation shows that the signature is correctly generated from the input digest then a mac will be computed based on an input nonce stored in tempkey and the value of the io protection secret which is stored in bo th the ATECC608A and the host mcu. mac outputs can only be generated in external and stored mode. the io protection function must be enabled for mac computation. see below for specific details on the mac message. the verify command can operate in four diff erent modes: 1. external mode the public key to be used is an input to the command. prior to this command being run, the message should be written to tempkey using the nonce command. in this mode the device merely accelerates the public key computation and r eturns a boolean result. 2. stored mode the public key to be used is found in the keyid eeprom slot. the message should have been previously stored in tempkey or the message digest buffer. if the following configuration checks for the public key at keyid suc ceed, the public key verification computation is performed and a boolean result is returned to the system; otherwise, the command returns an execution error. ? if keyconfig[keyid].pubinfo is one, then the key must have been previously validated using the ver ify command. ? if keyconfig[keyid].reqauth is set, then a previous key authorization must have been performed with either the verify or checkkey commands based on the key in keyconfig.authkey. ? if keyconfig[keyid].keytype indicates an ecc curve not supported by the device or indicates ?not an ecc key,? then this command will fail. ? this mode is used to set the key authorization information when the keyconfig.authkey field within some other slot points to keyid. if the verification succeeds, then an internal aut hcomplete flag will be set and keyid retained. see section 4.4.8 , authorized keys . ? data1 and data2 must be 32 bytes, and data3 & data4 should be zero length. 3. validate and invalidate mode s the validate and invalidate modes are used to validate or invalidate the public key stored in the eeprom at keyid. the signature is input to the device and a partial message should be in tempkey. the verifying public key is found at slotconfig[keyid].readkey, and the ecdsa verify message is composed of keyid and tempkey, formatted as noted below. only keyids 8 ? 15 can be validated; therefore, this command will return an error if keyid is 0 ? 7. ? if the ecc verification passes, then the most significant four bits of the first byte of block 0 of the public key at keyid will be set to 0x5 for validate and 0xa for invalidate. see section 5.1.1 , ecc key formatting . ? key (in)validation takes place regardless of the state of the lockvalue byte and/or the slotlocked bit corresponding to this slot. ? if the x509format byte corresponding to the specified key is non - zero, then the verify command will return an error. otherdata[17]:bit0 represents the validity of the key being acted on. it must be a ? 0 ?(invalid) to permit the validation operation, or a ? 1 ? (valid) to permit the invalidation operation. if otherdata[17]:bit0 does not match mode:2 in validate/invalidate modes, then this command will return an error. data1 and data2 sizes are the same as stored mode. ATECC608A - preliminary ?2017 microchip technology page 105 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 4. validateexternal mode the validateexterna l mode is used to validate the public key stored in the eeprom at keyid when x.509 format certificates are to be used. the digest of the message must be tempkey. tempkey must have been generated using the sha(public) command, and the key for that computati on must be the same as keyid. the verifying public key is found at slotconfig[keyid].readkey, and the ecdsa verify message is composed of keyid and tempkey, formatted as below. only keyids 8 to 15 can be validated, so this command will return an error if k eyid is 0 ? 7. ? if the ecc verification passes, then the most significant four bits of the first byte of block 0 of the public key at keyid will be set to 0x5 . see section 4.4.3 , created ecc keys . ? key validation takes place regardless of the state of the lockvalue byte and/or the slotlocked bit corresponding to this slot. ? if the x509format byte corresponding to the specified key is zero, then the verif y command will return an error. ? data1 and data2 sizes must be 32 bytes each. data3 and data4 should both be zero length. regardless of the mode, if the public key is stored within an eeprom slot and if keyconfig.reqrandom is set for that slot, then the va lue in tempkey must have been generated using the random number generator within ATECC608A. the message digest buffer may not be used for the message in this case. table 11 - 53. input parameters name size notes opcode verify 1 0x45 param1 mode 1 mode[0:2] 000 : stored mode. 001 : validateexternal mode. 010 : external mode. 011 : validate mode. 111 : invalidate mode. 100- 110 : do not use mode[3:4] must be zero. mode[5] : if 1, the message to be verified should come from the message digest buffer, otherwise the message should be in tempkey. ignored unless mode[0:2] is 000 or 010. mode[6] : must be 0 mode[7] : if 1, a validating mac will be appended to the output. ignored unless mode[0:2] is 000 or 010. param2 keyid 2 if mode:0 - 2 is stored mode, keyid contains the number of the slot containing the public key to be used for the verification. keyconfig[keyid].keytype determines the curve to be used. if mode:0 - 2 is validateexternal mode, keyid contains the number of the slot containing the public key to be validate d which must have been specified by a previous sha (public) command. the parent key to be used to perform the validation is stored in slotconfig[keyid].readkey and keyconfig[parentkey]. keytype determines the curve to be used. if mode:0 - 2 is external mode, keyid contains the curve type to be used to verify the signature. the value in this field is encoded identically to the keytype field in the keyconfig words within the configuration zone. if mode:0 - 2 is validate or invalidate mode, keyid contains the numbe r of the slot containing the public key to be (in)validated. the parent key to be used to perform the (in)validation is stored in slotconfig[keyid] keyprop.validatekey. slotconfig[parentkey].algoinfo determines the curve to be used. ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 106 ? 2017 microchip technology name size notes data1 r 32 the r component of the ecdsa signature to be verified. data2 s 32 the s component of the ecdsa signature to be verified. data3 x 0 or 32 the x component of the public key to be used for verification if mode:0 - 1 is external. data4 y 0 or 32 the y component of the public key to be used for verification if mode:0 - 1 is external. data5 otherdata 0 or 19 if validate mode, the bytes used to generate the message for the validation. x and y should be zero length in this mode and this parameter comes immediately after s in the input parameter stream. should be zero length for all other modes. table 11 - 54. output parameter name size notes response 1 returns a value of zero if the signature of the message can be verified using the public key. returns a value of one if the signature does not match, or another error code if there is some form of parsing or execution error. if a validation mac is to be computed by the device (i.e. mode:7 is set), this will be computed as the sha - 256 digest of the following message: 32 bytes contents of the io protection key 32 bytes message. from tempkey if mode:5 is 0, else first 32 bytes of message digest buffer 32 bytes system nonce. first 32 bytes of message digest buffer if mode:5 is 0, else second 32 bytes of message digest buffer 64 byte signat ure passed to device as data1/2 4 bytes input parameters (opcode, mode, param2) the message to be used for the ecdsa verify operation depends on the mode as follows: ? stored, external modes either tempkey or the message digest buffer should contain the sha - 256 digest of the message, depending on mode:5. ? validateexternal modes the contents of tempkey should contain the sha - 256 digest of the message. ? validate or invalidate mode the contents of tempkey should contain a digest of the publickey at keyid. it mus t have been generated using the genkey command over the keyid slot. the device then generates a message based on the same format as the sign(internal) command, except that the parameter and state bytes are copied from the input parameter otherdata. the mes sage is formatted as follows: 32 bytes tempkey (must have been generated by genkey) 1 byte sign opcode 10 bytes otherdata[0:9] 1 byte sn[8] 4 bytes otherdata[10:13] 2 bytes sn[0:1] 5 bytes otherdata[14:18] ATECC608A - preliminary ?2017 microchip technology page 107 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 this message is hashed using sha - 256 and used as the message input to the ecc verify operation. 11.23 write command the write command writes either one four byte word or an 8 - word block of 32 bytes to one of the eeprom zones on the device. depending upon the va lue of the writeconfig byte for this slot, the data may be required to be encrypted by the system prior to being sent to the device. this command cannot be used to write slots configured as ecc private keys (see privwrite). the following restrictions apply to writes within zones using this command: ? configuration zone: if the configuration zone is locked or zone:6 is set, then this command returns an error; otherwise the bytes are written as requested. any attempt to write any byte for which writes are perma nently prohibited (see section 2.2 , eeprom configuration zone ) results in a command error with no modifications to the eeprom. ? otp zone: if the otp z one is unlocked, then all bytes can be written with this command. if the otp zone is locked writes to the otp zone are never permitted. ? data zone: if the data zone is unlocked, then all bytes in all zones can be written with either plain text or encrypted data. after the data zone is locked, the values within the writeconfig bytes control access to the data slots. if the writeconfig bits for this slot are set to always , then the input data should be passed to the device in the clear. if bit:14 of slotconfig is set to one, then the input data should be encrypted and an input mac calculated. if the slot is individually locked using slotlocked, then this command always returns an error. four byte writes are only permitted in the data zone if all of the followin g conditions are met: ? slotconfig.issecret must be zero. ? slotconfig.writeconfig must be always. ? the input data must not be encrypted, i.e. zone:6 must be zero. ? the data/otp zones must be locked. four byte writes are never permitted in the otp zone. the two input address bytes are formed as described in section 10.5 . the least significant three bits, address[0:2], indicate the word within the block, or they are ignored if an entire 32 byte block is being written. address[3:6] contains the slot number for writes to the data zone, or the block number for the configuration and otp zones. for the data zones, address[8:9] is used to indicate the block within the slot. address values beyond the size of the specified zone result in the command returning an error. for slots 8 to 15, if keyconfig.pubinfo indicates that the slot contains an ecc public key which can be validated, then the key will be invalidated by writing 0xa to the most significant four bits of byte zero of block 0 of the slot when any block within the slot is written. if keyconfig.pubinfo is zero, then the most significant four bits of byte zero of block 0 of the slot are written with the data from the input parameter. if keyconfig.pubinfo is one and the ecc public key has been validated, then writes will fail if writeconfig is set to 0001 (pubinvalid). use verify(invalidate) to invalidate the public key prior to writing. any attempt to write the otp and/or data zones prior to the configuration zone being locked results in the device returning an error code. when writing to the data zone, if the corresponding slotlocked bit is zero, then this command returns an error regardless of whether or not the otp/data zones have been locked. ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 108 ? 2017 microchip technology 11.23.1 input data encryption the input data may be encrypted to prevent snooping on the bus during personalization or system operation. the system should encrypt the data by xoring the plain text with the current value in tempkey. upon re ceipt, the device will xor the input data with tempkey to restore the plain text prior to writing to the eeprom. whenever the data is encrypted, an authorizing input mac is always required. this mac is computed as follows: sha - 256(tempkey, opcode, param1, param2, sn[8], sn[0:1], <25 bytes of zeros>, plaintextdata) prior to locking of the otp/data zones, zone:6 is used to indicate to the device whether or not the input data is encrypted. after locking of the otp/data zones, zone:6 is ignored and only bit 14 of the slotconfig corresponding to the slot being written is used to determine whether or not the input data is encrypted. if data encryption is indicated, tempkey must be valid prior to this command being called, and it must be the result of gendig . speci fically, this means that tempkey.valid and tempkey.gendigdata must both be set to one. the last slot used by gendig for tempkey creation and stored in tempkey.keyid must match that in slotconfig.writekey. prior to data locking, any key can be used to gener ate tempkey and the gendigdata bit is ignored. the keyconfig.reqrandom, keyconfig.reqauth and keyconfig.authkey are ignored by this command because they will have been checked by the gendig command for the parent encrypting key. when performing an encrypted write to a partial block at the end of slots 0 thru 7 and 9 thru 15, all 32 bytes of input must be sent to the device, with the unused bits being used only as part of the mac calculation. their value will not affect the final contents of the eepr om. table 11 - 55. input parameters name size notes opcode write 1 0x12 param1 zone 1 bits 0 C 1: select among config, otp or data. see section 10.5.1 , zone encoding . bits 2 C 5: must be zero. bit 6: 1 = the input data has been encrypted; otherwise the input data is in the clear. ignored after the data zone is locked. bit 7: 1 = 32 bytes will be written; otherwise four bytes are written. param2 address 2 address of first word to be written within the zone. see section 10.5 data_1 value 4 or 32 information to be written to the zone may be encrypted. data_2 mac 0 or 32 message authentication code to validate address and data. table 11 - 56. output parameter name size notes success 1 upon successful completion, ATECC608A returns a value of zero. ATECC608A - preliminary ?2017 microchip technology page 109 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 12 compatibility 12.1 microchip atecc508a atecc08a is designed to be fully compatible with the atecc508a devices with the limited exception of the functions listed below. if the ATECC608A is properly configured, software written for the atecc508a should work with the ATECC608A without any required changes, again with the exception of the functions listed below . most elements of the configuration zone in the ATECC608A are identical in both location and value with the atecc508a. however the initial values that had been stored in the lastkeyuse fiel d may need to be changed to conform to the new definition of those bytes which can be found in this document. that field contained the initial count for the slot 15 limited use function which is supported in the ATECC608A via the monotonic counters. new features in ATECC608A vs. atecc508a ? secure boot function , with io encryption and authentication ? kdf command, supporting prf, hkdf, aes ? aes command, including encrypt/decrypt ? gfm calculation function for gcm aead mode of aes ? updated nist sp800 - 90 a/b/c rand om number generator ? flexible sha/hmac command with context save/restore ? sha command execution time significantly reduced ? volatile key permitting to prevent device transfer ? transport key locking to protect programmed devices during delivery ? counter limit ma tch function ? ephemeral key generation in sram, also supported with ecdh and kdf ? verify command output can be validated with a mac ? encrypted output for ecdh ? added self test command, optional automatic power - on self test ? unaligned public key for built - in x.5 09 cert key validation ? optional power reduction at increased execution time ? programmable i2c address after data (secret) zone lock features eliminated in ATECC608A vs. atecc508a ? hmac command removed, replaced via new more powerful sha command ? otp consumption mode eliminated, now read only ? pause command eliminated along with related selector function in updateextra ? slot 15 special limited use eliminated, replaced with standard monotonic counter limited use ? sha command no longer uses tempkey during c alculation, result in tempkey is unchanged 12.2 microchip atsha204a, atecc108a the ATECC608A is generally compatible with all atsha204/a and atecc108/a devices. if properly configured, it can be used in most situations where these devices are currently employed . for atsha204a and atecc108a compatibility restrictions, see the atecc508a datasheet. ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 110 ? 2017 microchip technology 13 mechanical 13.1 pinouts the device is offered in multiple packages: 8 - lead soic, 8 - pad udfn, and 3 - lead contact (i.e. non - solder) package. the pinout is as follows: figure 13 -1. package pinouts name pin sda 5 scl 6 v cc 8 gnd 4 nc 1, 2, 3, 7 13.2 wiring configuration for single - wire interface using the single - wire interface allows the connection of ATECC608A to a host using only a single pin (sda) to transfer data in both directions. this interface does not use the scl pin, which should be tied to ground. to prevent forward biasing the internal diode and drawing current across power planes in the system, the resistor pull - up on the sda pin should either be connected to the same supply that is connected to the v cc pin or to a lower voltage rail. if the signal levels for sda are different than the v cc voltage, consult the parametric specifications section of this document to ensure that the signal levels are such that excessive leakage current will be minimized when in sleep modes. this situation might occur if the ATECC608A device is physically distan t from the bus master device and the supply voltage for the bus master is different than the supply voltage for ATECC608A. figure 13 -2. 3 - wire configuration for single - wire interface ATECC608A - preliminary ?2017 microchip technology page 111 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 14 ordering information microchip ordering code ( 2 ) package delivery information inte rface configuration form quantity ATECC608A - sshcz - t 8- lead soic tape and reel 4,000 per reel single - wire ATECC608A - sshcz - b bulk in tubes 100 per tube ATECC608A - sshda - t tape and reel 4,000 per reel i 2 c ATECC608A - sshda - b bulk in tubes 100 per tube ATECC608A - mahcz - t 8- pad udfn tape and reel 15,000 per reel single - wire ATECC608A - mahda - t i 2 c ATECC608A - mahcz - s 3,000 per reel single - wire ATECC608A - mahda - s i 2 c ATECC608A - rbhcz - t (1 ) 3- lead contact tape and reel 5,000 per reel single - wire notes 1. please contact microchip for availability. 2. please contact microchip for thinner packages. 14.1 part marking as part of microchip?s overall security features the part mark for all crypto devices is intentionally vague. the marking on the top of the package d oes not provide any information as to the actual device type or the manufacturer of the device. the alphanumeric code on the package provides manufacturing information and will vary with assembly lot. ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 112 ? 2017 microchip technology 15 errata ATECC608A - preliminary ?2017 microchip technology page 113 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 16 package drawings 16.1 8 - lead soic dr a wing n o . re v . title gpc common dimensions (unit of measure = mm) symbol min nom max note a1 0.10 ? 0.25 a ? ? 1.75 b 0.31 ? 0.51 c 0.17 ? 0.25 d 4.90 bsc e 6.00 bsc e1 3.90 bsc e 1.27 bsc l 0.40 ? 1.27 0 ? 8 ? e 1 n top view c e1 end view a b l a1 e d side view package drawing contact: packagedrawings@atmel.com 8s1 h 3/6/2015 notes: this drawing is for general information onl y . refer to jedec drawing ms-012, v ariation a a for proper dimensions, tolerances, datums, etc. 8s1, 8-lead (0.150? wide body), plastic gull wing small outline (jedec soic) swb ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 114 ? 2017 microchip technology 16.2 8 - pad udfn dr a wing n o . re v . title gpc 8ma2 h 11/2/15 8ma2, 8-pad 2 x 3 x 0.6mm bod y , thermally enhanced plastic ultra thin dual flat no-lead package (udfn) ynz common dimensions (unit of measure = mm) symbol min nom max note a 0.50 0.55 0.60 a1 0.0 0.02 0.05 a2 - - 0.55 d 1.90 2.00 2.10 d2 1.40 1.50 1.60 e 2.90 3.00 3.10 e2 1.20 1.30 1.40 b 0.18 0.25 0.30 3 c 0.152 ref l 0.35 0.40 0.45 e 0.50 bsc k 0.20 - - t o p view side view bot t om view package drawing contact: packagedrawings@atmel.com c e pin 1 id d 8 7 6 5 1 2 3 4 a a1 a2 d2 e2 e (6x) l (8x) b (8x) pin#1 id k 1 2 3 4 8 7 6 5 notes: 1. this drawing is for general information onl y . refer to drawing mo-229, for proper dimensions, tolerances, datums, etc. 2. the pin #1 id is a laser-marked feature on t op v ie w . 3. dimensions b applies to metallized terminal and is measured between 0.15 mm and 0.30 mm from the terminal tip. if the terminal has the optional radius on the other end of the terminal, the dimension should not be measured in that radius area. 4. the pin #1 id on the bottom v iew is an orientation feature on the thermal pad. c ATECC608A - preliminary ?2017 microchip technology page 115 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 16.3 3 - lead contact dr a wing n o . re v . title gpc common dimensions (unit of measure = mm) symbol min nom max n o te d 2.40 2.50 2.60 e 6.40 6.50 6.60 a 0.45 0.50 0.55 e 1.60 1.70 1.80 b 1.90 2.00 2.10 l 2.10 2.20 2.30 f 0.30 0.40 0.50 g 0.05 0.15 0.25 h 2.30 2.40 2.50 j 4.30 4.40 4.50 package drawing contact: packagedrawings@atmel.com 3rb 01 1/31/11 3r b , 3-lead 2.5x6.5mm bod y , 2.0 mm pitch, con t act p ackage. (s a wn) rhb ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 116 ? 2017 microchip technology 17 revision history doc. rev. date comments 1111 03/10/2017 re - write from 3/1/17 version of atecc508a datasheet 1111 03/17/2017 refinement of multiple rough draft issues in first version, formatting cleanup 1111 03/24/2017 minor updates including new persistent latch section 1111 04/07/2017 fixed broken cross - reference links. added long twatchdog spec. fixed character spacing issues. other minor clarifications 1111 08/06/2017 converted to microchip word template . updated most atmel references to say microchip ATECC608A - preliminary ?2017 microchip technology page 117 1111 - cryptoauth - ATECC608A - datasheet_08 /6 /2017 atmel corporation 1600 technology drive, san jose, ca 95110 usa t: (+1)(408) 441.0311 f: (+1)(408) 436.4200 www.atmel.com ? 2017 atmel corporation. / rev.: atmel - 1111 - cryptoauth - atecc6 08a - datasheet_07/27/2017 . atmel confidential: for release only under non - disclosure agreement (nda) atmel ? , atmel logo and combinations thereof, enabling unlimited possibilities ? , cryptoauthentication?, and others are registered trademarks or trademarks of atmel corporation in u.s. and other countries. disclaimer: the information in this document is provided in connection with atmel products. no license, express or implied, b y esto ppel or otherwise, to any intellectual property right is granted by this document or in connection with the sale of atmel products. except as set forth in the atmel terms and conditions of sales located on the atmel website, atmel assumes no liability what soever and disclaims any express, implied or statutory warranty relating to its products including, but not limited to, the implied warranty of merchantability, fitness for a particular pur pose, or non - infringement. in no event shall atmel be liable for an y direct, indirect, consequential, punitive, special or incidental damages (including, without limitation, damages for loss and profits, business interruption, or loss of information) arising out of t he use or inability to use this document, even if atmel has been advised of the possibility of such damages. atmel makes no representations or warranties with respect to the accuracy or completeness of the contents of this document and reserves the right to make chang es to specifications and products descriptio ns at any time without notice. atmel does not make any commitment to update the information contained herein. unless specificall y provided otherwise, atmel products are not suitable for, and shall not be used in, automotive applications. atmel products are not intended, authorized, or warranted for use as components in applications intended to support or sustain life. safety - critical, military, and automotive applications disclaimer: atmel products are not designed for and will not be used in conne ction wi th any applications where the failure of such products would reasonably be expected to result in significant personal injury or deat h (?safety - critical applications?) without an atmel officer's specific written consent. safety - critical applications include , without limitation, life support devices and systems, equipment or systems for the operation of nuclear facilities and weapons systems. atmel products are not designed nor intended for use in military or aerospace applications or environments unless spec ifically designated by atmel as military - grade. atmel products are not designed nor intended for use in automotive applications unless specifically designated by atme l as automotive - grade. ATECC608A - preliminary 1111- cryptoauth - ATECC608A - datasheet_08 /6 /2017 page 118 ? 2017 microchip technology |
Price & Availability of ATECC608A
 |
|
|
|
|
All Rights Reserved © IC-ON-LINE 2003 - 2022 |
| [Add Bookmark] [Contact Us] [Link exchange] [Privacy policy] |
|
Mirror Sites : [www.datasheet.hk]
[www.maxim4u.com] [www.ic-on-line.cn]
[www.ic-on-line.com] [www.ic-on-line.net]
[www.alldatasheet.com.cn]
[www.gdcy.com]
[www.gdcy.net] |